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[57] ABSTRACT 

An electronic cash protocol including the steps of using a 
one-way function f^x) to generate an image f^xj from a 
preimage x x ; sending the image f A (x,) in an unbiinded form 
to a second party; and receiving from the second party a note 
including a digital signature, wherein the note represents a 
commitment by the second party to credit a predetermined 
amount of money to a first presenter of the preimage x x to 
the second party. 
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UNTRACEABLE ELECTRONIC CASH well known in the ait; and descriptions can be found in 

publicly available literature on cryptography, e.g. Applied 

BACKGROUND OF THE INVENTION Cryptography. Bruce Schneier. John Wiley & Sons. Inc. 

The invention generally relates to electronic cash systems. ( 199 *>* The anonymity of spenders as well as guaranteeing 

™ i • . • ^ i r i ^_ • t~ . 3 ^ CU * electronic coins Validity, but also the coins used are 

The ultimate intuitive goal of an electronic cash system is f U i a * w- * *u 

i_. > , ~ , , . , u / • unforgeable and cannot be spent more than once, 

to combine the best features of physical cash (privacy, ° 

anonymity. unforgeabiUty) with the best features of elec- m general, in one aspect, the invention is an electronic 

tronic commerce (speed, ease and potential security of P rotoco1 blading me ste P s <* usio 8 a one ~ wav wnc - 

transport and storage). The fundamental difficulty with tion 10 fi eneratc 30 iraa g e f i( x i) from a preiraage x 4 ; 

attempting to implement anonymous electronic cash, 10 sendin S * e f £i> in an unblinded form to a second 

however, is simple to state: if the possessor of an electronic and receiving from the second party a note including 

"coin" is not identified in two successive transactions, then a signature. The received signed note represents a 

how is he or she to be prevented from acting as if the first commitment by the second party to credit a predetermined 

transaction never occurred, and spending the same coin of ™>™y to a first P^enter of the preimage x 1 to 

again. The first proposed solution to this problem was ^ c second party. 

presented by Chaum, Fiat and Naor (see D. Chaunx A Fiat Preferred embodiments include the following features, 

and M. Naor, Untraceable Electronic Cash, Proc. CRYPTO The electronic cash protocol also includes sending the 

*88, Springer- Verlag (1990). pp. 319-327.). and was based preimage x A to a third party as payment for purchase of 

on the premise that it would be sufficient for such "double goods or services from the third party. Alternatively, it 

spending" to be detected, and the spender identified, upon 20 further includes selecting a second preimage x 2 ; using a 

presentation of the same "electronic coin" twice to the second one-way function f 2 (x) to generate a second image 

central bank. This premise has also been used in a number ^(^z) from the second preimage x 2 ; sending the first pre- 

of other proposed solution, all with the advantage that the image ^ and the unblinded form of the second image f 2 {xj 

bank need not be involved in each transaction. Practically 1$ to foe second party; and receiving from the second party a 

speaking, however, this premise has enormous drawbacks. n °te including a digital signature, the note representing a 

Fraudulent transactions are detected only long after they commitment by the second party to credit the predetermined 

have taken place, and if the perpetrator can be confident of amount of money to a first presenter of the second preimage 

not being brought to justice (either by being inaccessible or x 2 to the second party. In both cases. f,(x) and f 2 (x) are the 

by managing to use someone else's identity and cash), then „ same function. In the latter case, the sending of the first 

he or she can double-spend at will. preimage x x and the unblinded form of the second image 

However, if such fraudulent use of electronic cash is to be «*a> to mc is Performed anonymously and the 

prevented, men some authority must somehow be involved ^ 1S a banlL 

in each transaction as it occurs, so as to be able to recognize Also in preferred embodiments, the protocol includes the 

and alert targets of double-spending. How, then, is anonym- 35 steps of concatenating a signature key of a third parry with 

ity to be preserved. One approach is to rely on tamper- the first preimage x t to form a block of iirformation; encrypt- 

resistant hardware to force spenders to behave "honestly" ing the block of information by using an encryption key of 

(ie., not to double-spend) (see. for example, S. Even, 0. mc second party to generate an encrypted block of infor- 

Goldreich and Y. Yacobi, Electronic Wallet Proc. CRYPTO mation; and sending the encrypted block of information to 

'83, Plenum Press (1984), pp. 383-386.). Schemes based on 40 the third party. 

this premise are, however, extremely "brittle**. If anyone In general, in another aspect the invention is an electronic 

ever succeeds in tampering with the hardware, then not only cash protocol including the steps of receiving a first preim- 

is that person capable of double-spending, but anyone. age x ( from a first party, wherein the preimage ^ produces 

anywhere who obtains (e.g. purchases, perhaps) the infor- a first image f^x A ) when processed by a first one-way 

mation hidden in the hardware can spend arbitrarily high 45 function f x (x) and there being associated with said first 

amounts at wilL Current tamper resistance technology is far preimage \ 1 a commitment by a second party to credit a 

from being dependable enough to be trusted to thwart such predetermined amount ofmoney to a first presenter to the 

an enormous risk. second party of said first preimage x t ; selecting a second 

Another approach is cryptographic. For example, under preimage x 2 ; using a second one-way function f 2 (x) to 

certain very strong cryptographic assumptions, it is possible 50 generate a second image f 3 (xj from the second preimage 

to construct protocols that create "blinded" cash — x 3 ; sending the first preimage x i and an unblinded form of 

information which can be recognized later as valid cash, but the second image f 2 (x 2 ) to the second party; and receiving 

cannot be connected with any particular run of the protocol. from the second party a note including a digital signature, 

(See, for example. D. Chaum. Privacy Protected wherein the note represents a commitment by the second 

Payments — Unconditional Payer and/or Payee 33 party to credit the predetermined amount of money to a first 

Untraceability. SMART CARD 2000: The Future of IC presenter of the second preimage x 2 to the second party. 

Cards — Proc. IFTP WG 11.6 Int'l Conf., North-Holland In general in yet another aspect, the invention is an 

(1989). pp. 69-93; and D. Chaum, Online Cash Checks, electronic cash protocol including the steps of receiving 

Proc. EUROCRYFT *89, Springer- Verlag (1989), pp. from a first party an encrypted block of information, wherein 

288-293.) 60 the block of encrypted information was generated by first 

summary of thf tnvfn™n concatenating a public signature key of a second party with 

SUMMARY OF THE INVENTION Q fifSt Xi iQ form a block of information and then 

We present a simple, practical online electronic cash encrypting the block of information by using an encryption 

system based on the assumption of a network in which key of a third party; selecting a second preimage x 3 ; using 

anonymous, untraceable communication is possible. In 65 a second one-way function f 3 (x) to generate an image f(x^) 

general, the invention uses two simple primitives, namely a from the preimage x 3 ; forming a message including the 

one-way function and a signature scheme. These are both encrypted block of information along with the image f(xj in 
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an unblinded form; sending the message to the third party; anonymously, the bank can be required to honor it unless it 

and receiving from the third party a signed note including a can supply the associated x L . Of course, the bank can renege 

digital signature, wherein the note represents a commitment on an anonymously exchanged coin f(xj during the actual 

by the third party to credit a predetermined amount of money exchange, by claiming upon receiving x ; that the coin has 

to a first presenter of the pre image x 2 to the third party. 5 already been spent However, the bank cannot possibly 

In general, in still another aspect, the invention is an know who is being cheated by such a "dine and dash" ploy, 

electronic cash protocol including the steps of receiving is therefore vulnerable to monitoring and public expo- 

from a first entity an unblinded form of an Image f t (Xi) that surc - 

was generated by applying a one-way function f i(x) to a Finally, banks themselves are protected against couoter- 

preimage x 2 ; generating a message which contains a com- 10 feiting by the security of the digital signature scheme used 

mitment to credit a predetermined amount of money to a first to sign electronic coins. Moreover, they are protected against 

presenter of the preimage x L ; signing the message with a "double- spending" (or "double deposit") by their ability to 

digital signature; and sending the message along with the store x t values for coins in perpetuity, 

digital signature to the first party. Other advantages and features will become apparent from 

In preferred embodiments, the electronic cash protocol 15 the following description of the preferred ernbodiment and 

also includes subsequently receiving the preimage x 1 from a from the claims. 

third party; checking a database for the preimage x,; if the _ „, „ „ 

pwiiMge x, is not found in the database; xeditiog the third BRIEF DESCRIPTION OF THE DRAWING 

party with the predetermined amount of money; and adding FIG. 1 is a diagram of a non-anonymous withdrawal 

the preimage x t to the database. Alternatively, the protocol 20 protocol; 

includes subsequently receiving the preimage x l and an FIG. 2 is a diagram of an anonymous exchange protocol; 

unblinded image f^) from a third party, wherein the FIG. 3 is a diagram of an anonymous purchase protocol; 

unblinded image f 2 (x 2 ) was generated by applying a one- . . - . ./ 4 . 

way function f Jx) to a Vimage x 2 ; checking a database for 4 15 a rf * non-anonymous deposit protocol; 

the preimage x t ; if the preimage x A is not found in the 23 FIG. 5 is a diagram of an anonymous alternate payment 

database, generating a signed note including a digital protocol; 

signature, wherein the note represents a commitment to FIG. 6 is a diagram of an anonymous or non-anonymous 

credit the predetermined amount of money to a first pre- "drop" payment or money order protocol; and 

senter of the preimage x 2 ; and adding the preimage Xj to the FIG. 7 is a diagram of an encrypted money order protocol. 

database. 

t , . c . .... r *. DESCRIPTION OF THE PREFERRED 

Also in preferred ernbodiments. the invention features ^^^^ m^ODIMH^re^^^^ 

receiving a message from a second party, wherein the tLHiuuviMtw 

message was generated by concatenating an encryption key The ability to communicate anonymously is in some sense 

of a third party with a first preimage x A to form a block of 33 necessary a priori if anonymous cash transactions are to 

information, by encrypting the block of information by occur, since information about a party's communications 

using a first encryption key to generate an encrypted first will obviously reveal information about the party *s business 

block, and by concatenating an unblinded image f^x 2 ) to the dealings. In practice, the anonymity of communication may 

encrypted first block of information, wherein the unblinded be based on nothing more than confidence that the telephone 

image f^xj was generated by using a one-way function ^ company safeguards the confidentiality of its system. 

f 2 (x) to generate an image f 2 (Xj) from a preimage Xj. It Alternatively, parties may place trust in one or more "anony- 

further features decrypting the encrypted first block of mous remailers" to obscure identities of the parties , or rely 

information; generating a note including a digital signature. on an implementation of one of the other techniques from 

wherein the note represents a commitment to credit a the publicly available literature. 

predetermined amount of money to a first presenter of the ^ Suppose, not only that communications between parties 

preimage x 2 ; and sending the note to the second party. are anonymous with respect to third parties, but also that the 

In general, in yet another aspect, the Invention is an communicating parties are anonymous to each other. (In 

electronic cash protocol including the steps of sending an typical implementations, the latter condition is a natural 

unblinded image f 2 (xj to a second party, wherein the consequence of the former, barring self-identification.) A 

unblinded image f 2 (x 2 ) was generated by applying a ^ simple, somewhat anonymous electronic cash protocol in 

one-way function f 2 (x) to a preimage x 2 ; receiving a signed such a setting is shown in FIG. 1. 

note from the second party, wherein the unblinded note in the following descriptions of various protocols (see 

includes a digital signature and represents a commitment to FIGS. 1-7), we generally refer to three parties, namely, a 

credit the predetermined amount of money to a first pre- Customer 10, a Vendor 20. and a Bank 30. Customer 10 is 

senter of the preimage x 2 ; and in response to receiving the 55 0 f course generally, representative of the payor and Vendor 

unblinded note from the second party, authorizing the deliv- 20 Is generally representative of the payee. It should be 

cry of goods and/or services to a third party. understood, however, that these designations are chosen for 

The invention offers a simple, inexpensive way of doing purposes of clarity and that they are not meant to limit the 

cash-like transactions where the item of exchange (i.e., the scope of the invention. It would be just as valid to have 

withdrawn coin) has the properties of actual cash. For 60 referred to them as Party A, Party B and Party C. 

example, it is: (1) more or less anonymous; (2) secure; (3) In the figures, the different entities are represented by 

inexpensive to use; and (4) easy to carry around and blocks and the transfers of information from one entity to 

exchange. another are indicated by lines interconnecting the appropri- 

Parties are protected against a dishonest bank's reneging ate blocks. Each line represents a transfer of certain infor- 

on withdrawn coins by the fact that they keep secret the 65 mation from one entity to another in the direction indicated 

value x t for a particular coin until it is spent. As long as a by an arrow at the end of the line. The information that is 

particular coin f(x 1 ) is deposited publicly and non- transferred is summarized symbolically below the lines. 
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Though each block is labeled and will be described below monetary value with f(x x ). Bank 36 complies by digitally 

as representing a particular entity, it can be implemented by signing a statement to that effect thus "certifying" f(Xj) as 

a computing device which performs the computations and - a valid coin and debits an account which Customer 10 

the communications that are carried out by that entity. The maintains at Bank 30 by the amount of the value of the coin, 

computing devices might be any of a large variety of 5 In other words* Bank 30 issues a statement or representation 

electronic devices including, for example, a personal which indicates in effect that 'The first presenter of me 

computer, a PCMCIA card, a PDI a smart-card, a palm-top pmmage of f(x,) will be credited an amount 7T and then 

computer, or a more powerful workstation, just to name a Bank 30 01 representation, 

few. The bark side of the protocols that are described below Techniques for signing or certifying information (e.g. by 

can be implemented by a server programmed to handle 10 ^ a P nvatc ^W^*. key pair) and the use of digital 

-i^*™;,* ^™™*;™c c™u.- ^ %w* ~.T~ n tUr signatures are well known in the art For further details, refer 

a™^^ * "V of * e recognized references in the field, e.g. 

handle ATM transactions. The server would have multiple ^ Cryptogrc&ytyBwt Schneiex. John Wiley & 

telephone lines coming into it and include data storage ^ s ^ (1994) 

capability for storing the relevant data. ^ In general, a signature scheme is a way of tagging a script 

It should of course also be understood that the computing 15 ft uscs a pubifc key-private key pair. Public-private 

devices include, either internally or externally, all of the k evs ^ ^ implemented using one-way functions, although 

memory that is required for the data and programs that are a somewhat more practical approach is to use a trap door 

involved in implementing the protocols. Further more, they function, which tends to be more efficient (e.g. see RSA, 

include devices (e.g. a modem) which enable them to DSS, ElOamal algorithms described by Schneier), The pri- 

communicate with other computing devices. Li addition, the 20 V ate key is used to encrypt either the script or a hash of the 

communications media over which the transfers of informa- script to produce a digital signature that is then appended to 

tion take place can also be any of a large number of the script The digital signature represents a signature of the 

possibilities, including telephone lines, cable, the Internet entity which owns the private key since no other entity can 

satellite transmissions, or radio transmissions, for example. generate such a signature from that script. If a second entity 

In other words, it is not intended that the invention be limited 25 can decrypt the tag using the public key. it knows that the 

with regard to either the types of devices that are used or the signature was generated by the entity which owns the private 

methods of communication that are employed The possi- ^ey. 

bilities and combinations are limited only by one's irnagi- Obviously, for certification to work, it is assumed that 
nation everyone has and trusts the signing authority's public key 
For the following protocols, it is assumed that Bank 30 30 «* has confidence that the private key has not been corn- 
chooses and makes publicly available a one-way function promised. 

f(x). Alternatively, such a function could be made publicly By publicizing its public key and appending digital sig- 
available by any party so long as all parties to the transac- Datures to a representation that Bank 30 will pay a specified 
tions can access and use it. In general by a one-way ^ to the entity that first presents a preimage of f(x t ). Bank 
function, we mean a function f(x) such that using x, pro- 35 » Knta unambiguously to its cornrnitmeat and pro- 
duces fix,) and given f(x^ you cannot determine x r In the tects ltself would-be forgers, 
following description, x^wiH also be referred to as a preim- The certified representation that is generated by the bank 
age of f(x a ) and f(Xj) will be referred to as an image of x x . is designated herein as C(f(x,)), also referred to herein as a 

Id practice, perfect one-way functions may not actually «> te - ™snote is returned to Customer 10. In addition, the 

exist That is, for all functions now believed to be one way 40 note can be made publicly available since it is of no value 

functions, there may eventually be sufficient computing t0 wn0 docs not 

power or techniques f or detenmning x, given fXxJ.Tbus, by EXCHANGE PROTOCOL 

the phrase one-way function, we mean to also include those At any time, a party (e.g. Customer 10 or Vendor 20) can 

functions for which it is very difficult, but not necessarily ^ anonymously » excbange « a coin at Bank 30. Indeed, it is 

impossible, to compute x x by knowing f(x,). particularly important to do this immediately after receiving 

The one-way function can be any one of a number of a ^ fr om another party to minimize the risk mat some- 
standard hash functions (e.g. MD5, SHA, etc.). In addition, body else will supply x x to Bank 30 before the bona fide 
one could use several one-way functions and concatenate recipient of the coin. A dishonest party could try to send the 
them. There are a wide variety of one-way functions known ^ ^ mu itiple times by giving x l to multiple parries. If that 
in the art lypicaliy, many of them are easy to compute, and happens, the first recipient to reach Bank 30 will receive its 
thus they can be implemented on a smart card. valuc all other recipients of the coin will not be able to 

With that background, the various protocols which exchange it for another coin. For Vendor 20. the timing of 

embody the invention will now be described, starting with a the exchange is less crucial because presumably Vendor 20 

withdrawal protocol during which a customer obtains "cash" 33 will not deliver the goods or services that are being pur- 

from the bank. chased until being assured that the coin that was received is 

WITHDRAWAL PROTOCOL Referring to FIG. 2. assuming that Customer 10 wishes to 

A withdrawal is performed in the manner shown in FIG. anonymously exchange a coin. Customer 10 supplies to 

1 Customer 10 chooses a random number Xj and uses f(x) to 60 Bank 30 x t and another image of the function. f(x 2 ), for 

generate an image of x r The value x, is a random string some randomly chosen x 2 . In other words. Customer 10 

obtained from a random number generator to which some attempts to make a withdrawal as described earlier but 

post processing may optionally be applied. It may be. for simultaneously supplies the amount that is being withdrawn 

example. 128 bits long. Customer 10 keeps Xj secret until a as represented by x t . Bank 30 simply certifies f(x 2 ) and 

payment takes place and then it is sent as the payment 65 keeps x x in a database 40 as proof that f(Xi) has already been 

Customer 10 then withdraws a coin (non-anonymously) "spent**. It is this exchange that prevents double spending of 

from Bank 30 by requesting that Bank 30 associate a x v 
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Since f(Xj) and C(f(Xi)) are already in the possession of 
Bank 30. the sending of that information to Bank 30 along 
with x L and f(x 2 ) is optional. 

If the Bank's side of the protocol is implemented on a 
server, it automatically stores the x ( 's that are received. And 
each time Bank 30 receives another x,, the hank first checks 
it against the x/s that have already been cashed in (i.e., 
received). 

One can use a series of exchange transactions to obscure 
who actually is spending the coin. Note that during an 
exchange transaction, only f(x 2 ) need be disclosed but not 
the owner of x 2 . Unlike alternative approaches to achieving 
anonymity, blinding of the coin or other aspects of the 
transaction is not necessary. Indeed, it is desirable that f(x ( ) 
not be blinded but be made publicly known. 

Whatever steps one wishes to take to secure anonymity of 
communication is sufficient to secure anonymity of the 
transaction (i.e.. achieving anonymity is possible but it is 
also optional). 

This procedure can also be used to make change for a coin 
of a given value. Instead of sending f(x 2 ), the party seeking 
the change can send multiple f(x)* s, e.g. f^J. (x)'s f(x 3 ). f 
(x 4 ), each for a particular value and the total of which equals 
the value associated with tXXj), The bank returns multiple 
signed notes, Qffx,)). 

Purchase Protocol 

Referring to FIG. 3. the actual spending of coins uses a 
protocol that is similar to the exchange protocol. The spend- 
ing party (e.g. Customer 10) passes x t to the receiving party 
(e.g. Vendor 20). Since it is likely that Vendor 20 does not 
have direct and immediate access to f(x 4 ) and CXf^)), 
Customer 10 also includes this information as part of the 
transaction. Vendor 20 then immediately calls Bank 30 and 
exchanges x ; for a "fresh" coin, assuming that Bank 30 first 
verifies that it has not previously been spent Vendor 20 uses 
the exchange protocol illustrated in FIG. 2 to perform this 
exchange. Assuming that the exchange was successful. 
Vendor 20 then delivers to Customer 10 the goods and/or 
services that were purchased. 

DEPOSn PROTOCOL 

Referring to FIG. 4, unspent coins can also be deposited 
non-anonymously with Bank 30 at any time. For example, 
when Vendor 20 wishes to deposit a coin f(Xj) that it has not 
spent, it sends x t to Bank along with a deposit request 
Vendor 20 may also optionally send f(x x ) as well as the note 
C(f(x,)). 

Upon receiving x A and the deposit request Bank 30 
checks its database to determine whether x t has been 
previously presented to the Bank. Of course, if it had been 
previously presented. Bank 30 will not credit the Vendor's 
account and will report to Vendor 20 that it is not a valid 
coin. If Bank 30 has not previously received x 4 , it credits the 
Vendor's account with the appropriate amount and sends a 
deposit receipt to Vendor 20 confirming that a credit has 
been entered. 

EXTENSIONS TO THE PROTOCOLS 

The exchange payment protocols in the above-described 
electronic cash scheme permit a number of variations, which 
can be tailored to the available means of communication and 
the desired levels of anonymity. For example, referring to 
FIG. 5. if Customer 10 has easier access to Bank 30 than 
Vendor. 20, then Vendor 20 can first supply an f(Xj) to 
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Customer 10. who then performs the exchange protocol for 
Vendor 20 and returns the signed coin, i.e.. C^xJ). as proof 
of payment. As mentioned previously, the exchange protocol 
may be performed anonymously. 

5 Alternatively, if both Customer 10 and Vendor 20 have 
better communications access to Bank 30 than to each other, 
then the parties may use a "drop** payment protocol, such as 
is illustrated in FIG. 6. In accordance with this protocol. 
Customer 10 drops off the payment at Bank 30 for Vendor 

10 20 and Vendor 20 subsequently picks up the payment from 
Bank 30. 

The steps of the "drop" payment protocol are as follows. 
First Customer 10 supplies an x 2 for a valid coin of a 
specific amount to Bank 30. along with a public signature 

15 key p of Vendor 20. and other information relating to the 
transaction. For example, among the other information Cus- 
tomer 10 might wish to identify the goods being purchased, 
to identify the transaction and/ox the vendor, and to indicate 
the declared of the customer intentions regarding payment 

20 thereby essentially turning the cash into a kind of "electronic 
money order. Optionally. Customer 10 can also send f(x L ) 
and the note CCf^xJ). but as pointed out earlier, since this 
information is already available to Bank 30, sending it may 
not be necessary. 

23 Note that the a record that may be assembled from the 
other information supplied by Customer 10 may be of 
particular use in remote payment settings, where the nature 
of the transaction is not otherwise implicit in the action of 
payment itself, as is typically the case for in-person pay- 
ments. 

If Vendor 20 does not wish to remain anonymous, the 
public signature key may be publicly associated with the 
identity of Vendor 20; or if anonymity is desired, the public 

35 signature key can be a special-purpose public signature key 
with no associated identity. In the latter case, the public key 
is passed confidentially to trusted acquaintances or simply 
publicized under a pseudonym. 
Bank 30 agrees to assign the amount associated with x t to 

40 the first coin f(x<) presented to it that it is also signed using 
the private signature key that corresponds with the 
previously-delivered public signature key p. Thus to obtain 
the payment for the goods that Customer 10 wishes to 
purchase. Vendor 20 simply makes a withdrawal from Bank 

45 30 using the protocol previously described In connection 
with FIG. 1. That is. Vendor 20 randomly selects an x 2 . and 
uses f(x) to generate its image f(x z ). In this instance, 
however. Vendor 20 signs f(x^ with its private signature key 
before sending f(x 3 ) to Bank 30. In addition, in this case the 

M withdrawal is not from the account of the vendor but is 
simply a transfer of the amount previously supplied by 
Customer 10. 

Bank 30 uses the Vendor's public signature key of the 
vendor to verify that f(Xj) is signed by Vendor 20 (i.e.. by the 

55 party to whom the money transfer is to be made). Upon 
confirming the signature on f(Xj). Bank 30 issues a note 
C(f(x 2 )) which it sends to Vendor 20. 

After Vendor 20 receives the note C(f (Xj)) confirming that 
the money has been received. Vendor 20 sends the goods to 

60 Customer 10. of course, theoretically Bank 30 could cheat 
by simply keeping the money instead of assigning it to the 
payee. However, we rely on the anonymity of the payer or 
at least the possibility that the payer may be exposing the 
transaction to public monitoring to keep Bank 30 honest 

65 In a setting where caramunicatioos among the parties may 
be intercepted, there are a number of ways of securing the 
exchange protocols and. in particular, the secret x value 



03/02/2004, EAST Version: 1.4.1 



5,7( 

9 

passed therein from eavesdroppers. The most natural 
method is public key encryption. If parties know public 
encryption keys of each other, as well as of the bank, then 
all of the above protocols can function equally well in the 
eavesdropper-threatened setting, as long as every message, 
except those sent by Bank 30. is encrypted using the public 
encryption key of the receiver or using a symmetric "session 
key" encrypted using the receiver's public encryption key. 
The messages of the bank, of course, can be considered 
non-confidential, since they consist only of signed coins of 
the form fQO, with x 4 - kept secret by someone else. The use 
of message authentication codes, or MACs, with each 
encryption makes it possible also to ensure that the message 
is not even tampered with by someone other than the sender 
before arriving at Us destination. 

The use of public-key encryption also makes possible 
another kind of "electronic money order." In this case, which 
is illustrated in FIG. 7 and referred to generally as an 
encrypted money order protocol Customer 10 encrypts the 
secret x, value for some valid electronic coin, along with the 
public key p of Vendor 20 and any other desired identity or 
transaction information, as in the case of the previous "drop" 
protocoL Customer 10 encrypts this information by using 
the public encryption key of the bank or by using a session 
key which is then encrypted using the public encryption key 
of the bank. Customer 10 then sends the encrypted data 
directly to Vendor 20. 

To "cash" it. Vendor 20 selects a random value x 2 , 
generates its image f{x^) and appends f(x 2 ) to the message 
E that was received from Customer 10. As before, f(x 3 ) is to 
be signed by the bank so that it will represent the transfer of 
cash to Vendor 20. Vendor 20 signs the complete message 
(or at least f(x£) using the private signature key associated 
with public signature p. and passes E, f(x^) and the signature 
to Bank 30. Optionally. Vendor 20 may further encrypt this 
message in the manner described before, i.e., using the 
banks encryption key and possibly an additional symmetric 
key. 

After Bank 30 has decrypted the message from Vendor 20 
by using its private key. it then checks its database to 
determine if it does not already have Xj stored therein, and 
if it is not found. Bank 30 stores x L . Bank 30 then generates 
a note C(f(x 2 ) representing a cash transfer to Vendor 20 In 
the amount of the value associated with f(Xj). The note is 
then sent to Vendor 20 which after receipt and verification 
sends the purchased goods to Customer 10. 

In effect, this encrypted last protocol is identical to the 
previous one. The addition of encryption has simply per- 
mitted the payer to pass the "money order" via the payee, 
while ensuring that the secret and additional information 
provided by the payer is not tampered with. 

It may be beneficial for the note, C(f(x,). to include an 
expiration date. In that case, the stored x,s in the database of 
Bank 30 will not grow too large. That is, x x s will not have 
to kept around in the database of the Bank forever. To 
prevent the value of the coins from expiring, the smartcard 
(or whatever equipment is handling the customer's 
transactions) could automatically exchange the old coins for 
new ones with a new expiration date. 

The expiration date also makes the money refundable. If 
a user 1 s smartcard breaks and all of the x, s are lost, the user 
can simply present the f(x, ) to Bank 30 with the request that 
if they are not claimed within 3 months after the expiration 
date, then the user. e.g. customer 10 wants to be credited 
with the amount of the value of the coins. For this to work, 
however, during the original communication with Bank 30 
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at which time the coins are withdrawn. Customer 10 must 
identify himself or herself. 

The customer side of the protocols can be easily imple- 
mented using a smartcard since only the x/s need to be 

5 stored and they typically will not require a lot of memory. To 
prevent theft of the x/s by somebody who would steal the 
smartcard. a PIN can be used in the smartcard which is secret 
and which must be entered by the user before any of the x/s 
can be accessed. 

10 Note that it was also assumed that all of the interactions 
that were described above were automated. That is, they 
were automatically carried out by an appropriately pro- 
grammed computer or processor that was under the control 
of the party for whom the transaction is being implemented. 

Other embodiments are within the following claims. For 
example, another way to link identifying information to 
electronic coins is to use the secret value Xj to perform the 
linking. In the above-description, it was assumed mat the 

M secret values x, are generated randomly by the coin 's creator. 
The secret value can. however, be generated as the image of 
some identifying data under a one-way function h(x). which 
could perhaps be the same function f(x) that is used in the 
construction of normal electronic coins. The identifying 

M information might include the purpose and date of the 
payment and the name of the payer and the intended payee 
— in short, all of the information that the payer might have 
wished the bank to archive. This information would then be 
passed through h(x) to generate an x I( which serves as the 
secret value. 

In mis case, there would be no need for the bank to 
archive transaction information received with electronic 
payments in either the "drop" or "electronic money order" 
protocols described above, In fact all that is required is that 

33 the payment be labeled as requiring that the payee be 
non-anonymous. As long as the bank positively identifies the 
payee and keeps normal records of the transaction, including 
the payee's identity, the payer can later demonstrate **p a y- 
ership" by publicly revealing the pre-image of x^ under f(x). 

4C which as indicated above might include information regard- 
ing the purpose and date of the payment and the names of the 
payer and the intended payee. The payer can obtain coins 
with such implicitiy information carrying x,; values simply 
by constructing them normally, and men exchanging other 

45 coins for them, In this context however, the payment 
information need not even be sent to the bank, since it is 
implicitly contained in x,. Hence, the only information that 
the payer needs to pass securely to the bank is the public 
signature key to be used to identify the payee, which 

50 implicitly communicates the requirements that the payer be 
non-anonymous. 

In fact, even this latter requirement of signature-based 
payee identification can be eliminated if information is 
embedded in ^(or f(x ; ) to the effect that the bank is not to 

55 honor the cash non-anonyraously. For example, some prop- 
erty of x, (e.g. the value of the first bit being 1) might be 
publicly declared by the bank to indicate that the coin in 
question will only be honored non-anonymously. A payer 
can then generate a secret x, by computing f(sj), where s, is 

60 the concatenation of the payment information for an 
intended transaction with some random value r. chosen such 
that x, has the non-anonymity property. Note that the prop- 
erty should be chosen such that roughly half the pre-images 
Sj of f(s) of any particular length result in an f(sj) with the 

65 property, so that not many attempts to choose r will be 
necessary before one is found that has the desired effect on 
x,). This coin would now have the property that anyone 
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presenting it for redemption must also provide an identity 
and prove it to the bank's satisfaction so that the bank can 
record the identity of the exchanger as part of its normal 
accounting. As a result, the coin's creator would later be able 
to demonstrate its origin, as well as other details of the 
transaction in which it was intended to be used, by referring 
to the bank's accounting records and revealing the s Jt used 
to generate x,. Hence, even if the coin is spent completely 
normally, with no extra encryption or attendant information 
for the bank, it still provides the payer with all the protection 
furnished by the "electronic money order" described earlier. 
What is claimed is: 

1. A method of implementing an electronic cash protocol 
comprising the steps of: 

using a one-way function f t (x) to generate an image 

f 1 (x 1 ) from a preimage x A ; 
sending the image f ,(x : ) in an unblinded form to a second 

party; and 

receiving from the second party a note including a digital 
signature, said note representing a commitment by the 
second party to credit a predetermined amount of 
money to a first presenter of said preimage Xj to the 
second party. 

2. The method of claim 1 further comprising sending the 
preimage x, to a third party as payment for purchase of 
goods or services from the third party. 

3. The method of claim 1 further comprising: 
selecting a second preimage x 3 ; 

using a second one-way function f 3 (x)to generate a sec- 
ond image f 3 (x 2 ) from the second preimage x 2 ; 

sending the first preimage Xj and the unblinded form of 
the second image f 2 (x 2 ) to the second party; and 

receiving from the second party a second note including 
a digital signature, said second note representing a 
commitment by the second party to credit said prede- 
termined amount of money to a first presenter of said 
second preimage x 2 to the second party. 

4. The method of claim 3 wherein functions f x (x) and f 2 (x) 
are identical to each other. 

5. The method of claim 4 wherein the step of sending the 
first preimage x x and the unblinded form of the second 
image f^Xj) to the second party is performed anonymously. 

6. The method of claim 5 wherein the second party is a 
bank. 

7. The method of claim 3 further comprising sending the 
second preimage x 2 to a third party as payment for purchase 
of goods or services from the third party. 

8. The method of claim 1 further comprising: 
concatenating a signature key of a third party with the first 

preimage x l to form a block of information; 

encrypting the block of information by using an encryp- 
tion key of the second party to generate an encrypted 
block of information; and 

sending the encrypted block of information to the third 
party. 

9. A method of implementing an electronic cash protocol 
comprising the steps of: 

receiving a first preimage Xj from a first party, said 
preimage x A producing a first image fjCxJ when pro- 
cessed by a first one-way function f 1 (x) and there being 
associated with said first preimage Xj a commitment by 
a second party to a edit a predetermined amount of 
money to a first presenter to the second party of said 63 
first preimage x,; 

selecting a second preimage x 2 ; 
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using a second one-way function f 2 (x)to generate a sec- 
ond image f z (x^) from the second preimage x 2 ; 

sending the first preimage x 1 and an unblinded form of the 
second image fjCXj) to the second party; and 

receiving from the second party a note including a digital 
signature, said note representing a commitment by the 
second party to credit said predetermined amount of 
money to a first presenter of said second preimage x 2 to 
the second party. 

10. The method of claim 9 wherein functions f 4 (x) and 
fjCx) are identical to each other. 

11. The method of claim 9 wherein the step of sending the 
first preimage x A and the unblinded form of the second 
image f^xj to the second party is performed anonymously. 

12. A method of implementing an electronic cash protocol 
comprising the steps of: 

receiving from a first party an encrypted block of 
information, wherein said block of encrypted informa- 
tion was generated by first concatenating a public 
signature key of a second party with a first preimage x t 
to form a block of information and then encrypting the 
block of information by using an encryption key of a 
third party; 

selecting a second preimage x 3 ; 

using a second one-way function f 2 (x) to generate an 
image f(x£ from the preimage x 3 ; 

forming a message including the encrypted block of 
information along with the image f(x 2 ) in an unblinded 
form; 

sending the message to the third party; and 
receiving from the third party a signed note including a 
digital signature, said note representing a commitment 
by the third party to credit a predetermined amount of 
money to a first presenter of said preimage x 3 to the 
third party. 

13. The method of claim 12 wherein functions f t (x) and 
f 2 (x) are identical to each other. 

14. The method of claim 12 further comprising signing 
the message before sending it to the third parry, wherein the 
step of signing is performed using a private signature key 
corresponding to a public signature key possessed by the 
third party. 

15. The method of claim 12 wherein the second party is 
the party receiving the encrypted block of information from 
the first party. 

16. A method of implementing an electronic cash protocol 
comprising the steps of: 

receiving from a first entity an unblinded form of an 

image fi(x,) that was generated by applying a one-way 

function f t (x) to a preimage x 1 ; 
generating a message which contains a commitment to 

credit a predetermined amount of money to a first 

presenter of said preimage x t ; 
signing said message with a digital signature; and 
sending said message along with said digital signature to 

said first party. 

17. The method of claim 16 wherein the receiving party 
maintains an account for the first entity and wherein said 
protocol further comprises debiting the first party's account 
by the predetermined amount of money. 

18. The method of claim 16 further comprising: 
subsequently receiving the preimage x, from a third party; 
checking a database for the preimage x,; 

if the preimage x t is not found in said database, crediting 
the third party with said predetermined amount of 
money; and 
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adding the preimage x, to said database. 

19. The method of claim 16 further comprising: 
subsequently receiving the preimage x t and an unblinded 

image f^x^) from a third party, wherein the unblinded 
image f 2 (Xj) was generated by applying a one-way 3 
function f 2 (x) to a preimage x 2 ; 
checking a database for the preimage x t ; 

if the preimage x x is not found in said database, gener- 
ating a signed note including a digital signature, said l0 
note representing a commitment to credit said prede- 
termined amount of money to a first presenter of said 
preimage x 2 ; and 

adding the preimage \ i to said database. 

20. The method of claim 19 wherein functions f^x) and ^ 
f 2 (x) are identical to each other. 

21. The method of claim 16 further comprising: 
receiving a message from a second party, wherein said 

message was generated by concatenating an encryption 
key of a third party with a first preimage x t to form a 20 
block of information, by encrypting the block of infor- 
mation by using a first encryption key to generate an 
encrypted first block, and by concatenating an 
unblinded image f£x 2 ) to the encrypted first block of 
information, wherein said unblinded image f 2 (*2) wa5 25 
generated by using a one-way function f 2 (x) to generate 
an image f 2 (x 2 ) from a prcimagc x 2 ; 

decrypting the encrypted first block of information; 

generating a note including a digital signature, said note 
representing a commitment to credit a predetermined 
amount of money to a first presenter of said preimage 



30 



45 



sending said note to the second party. 

22. The method of claim 21 wherein functions f A (x) and 35 
f 2 (x) are identical to each other. 

23. The method of claim 21 further composing: 
checking a database for the preimage x A ; 
generating the signed note only if the preimage Xj is not 

found in said database; and 40 
adding the preimage x x to said database. 

24. A method of implementing an electronic cash protocol 
comprising the steps of: 

obtaining a first image f{Xj) and a first preimage x x . 
wherein said first preimage x t has a predetermined 
monetary value associated therewith; 

selecting a second preimage x^; 

using a second one-way function f 2 (x)to generate a sec- 
ond image f 2 (x 2 ) from the second preimage x 2 ; 50 

sending the first preimage x t and an unblinded form of the 
second image f 2 (x2> to the second party; and 

receiving from the second party a note including a digital 
signature, said note representing a commitment by Che 
second party to credit a ^determined amount of 33 
money to a first presenter of said second preimage x 2 to 
the second party, wherein said predetermined amount 
of money is no greater than said predetermined mon- 
etary value. 



25. The method of claim 24 wherein said predetermined 
amount of money is less than said predetermined monetary 
value, 

26. The method of claim 24 wherein fx^x) equals f 2 (x). 

27. A method of implementing an electronic cash protocol 
comprising the steps of: 

obtaining a first image fifrj) and a first preimage x r 

wherein said first preimage x, has a predetermined 

monetary value associated therewith; 
selecting a plurality of preimages x ( , wherein 1 is an 

integer index that runs from 1 to n, where n is a positive 

integer; 

using a second one-way function f 2 (x) to generate a 
plurality of images f 2 (x J from the second preimages x ( ; 

sending the first preimage x t and an unblinded form of all 
of the images f 2 (x,) to the second party; and 

receiving from the second party a plurality of each 
including a digital signature, said plurality of notes 
equal in number to the plurality of images f 2 (x^) and 
representing a plurality of predetermined amounts, 
each of said plurality of notes representing a commit- 
ment by the second party to credit a corresponding 
different one of said plurality of predetermined 
amounts of money to a first presenter of the corre- 
sponding preimage x t - to the second party, wherein the 
total of said plurality of predetermined amounts of 
money equals said predetermined monetary value. 

28. A method of implementing an electronic cash protocol 
comprising the steps of: 

obtaining a first image fXXj) and a first preimage x r 
wherein said first preimage x x has a predetermined 
monetary value associated therewith; 

concatenating a signature key of a second party with the 
first preimage x ( to form a block of information; 

encrypting the block of information by using an encryp- 
tion key of a third party to generate an encrypted block 
of information; and 

sending the encrypted block of information to the third 
party. 

29. The method of claim 28 further comprising concat- 
enating other information with the signature key of a second 
party and the first preimage Xj to form the block of infor- 
mation. 

30. A method of implementing an electronic cash protocol 
comprising the steps of: 

sending an unblinded Image f 2 (x 2 ) to a second party, 
wherein the unblinded image f 2 (x 2 ) was generated by 
applying a one-way function yx) to a preimage x^; 

receiving a signed note from the second party, said 
unblinded note including a digital signature, said 
unblinded note representing a ccmimitment to credit 
said pre4etermined amount of money to a first presenter 
of said preimage x 2 ; and 

in response to receiving the unblinded note from the 
second party, authorizing the delivery of goods or 
services to a third party. 
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[57] ABSTRACT 

A method for charging a consumer for access, over a 
network, to a vendor's information; in particular, a method 
for this pay -per- access over the Internet. The method uses a 
third-party, called a banker, to mint tokens identified with 
particular information a consumer might want to purchase. 
The tokens are immediately available to the consumer 
because of the consumer's having already established an 
account with the banker, and purchased what are here called 
credit units, which can have a value of only a fraction of a 
cent, allowing vendors to charge very little for access to their 
information. A token is pre -authorization for a consumer to 
pay for access for a particular page of information. In one 
embodiment, when a consumer makes a purchase, i.e. 
chooses to access a Web page for which a vendor makes a 
charge, the transaction is routed through the banker, which 
charges in credit units (those already on account), and 
credits the vendor account. The vendor later redeems for 
payment whatever credit units have been credited to the 
vendor's banker account, not necessarily only those credit 
units resulting from transactions with a particular consumer. 
In another embodiment, a vendor uses a franker to test if a 
token is valid; this enables the vendor to collect a token from 
a consumer and later redeem it for payment with a banker. 
The method also allows for a vendor and consumer to have 
accounts with different bankers. 

5 Claims, 5 Drawing Sheets 
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METHOD OF CHARGING FOR PAY-PER- charge is made, and all the methods require on-line 

ACCESS INFORMATION OVER A verification, which unavoidably slows a transaction. 

NETWORK Much of the prior art, whether for an account-based or 

token-based method, can be understood in terms of FIG. la. 

CROSS REFERENCE TO RELATED 5 In either kind of method, a consumer 19 first makes a 

APPLICATION payment to a broker 17 in exchange for scrip. The term scrip 

Reference is made to and priority claimed from U.S. is used here in a generic sense to indicate a data object used 

provisional application Sen No. 60/043,020, filed Apr. 15, m P lacc of money. As such, the term encompasses both 

1997, entitled INTERNET PAYLINK TRANSFER tokens and authorization to charge an account. The term 

METHOD. 10 payment is used here to indicate conveyance by a payer of 

money, as opposed to scrip, such as by a personal check, or 

BACKGROUND OF THE INVENTION authorization to charge the payer money, such as by charging 

„„,,..„.,, a credit card owned by the payer. 

1. Technical Field 

_ . . . „ c . . With the scrip purchased from the broker 17, the con- 

The present invention pertains to the field of charging a 15 sumercan chase in f ormatior] from arj information vendor 

fee for information provided over a network More 18 To do ^ sts the iaformation he 

particularly, the present invention pertains to a method of wants ^ ^ veador , s which indicates 

handling access to information over the Internet m a way (0 the 00wamCT thc ^ of ^ in f orma tion. The vendor's 

that makes feasible a quite small charge per access, and does ^toffece tQ me consumer will take scri for the amount 

not require the consumer to have an account with the 20 chargcd fof the informatioilf and seDd the ^usum™ the 

information provider. information. Finally, the vendor will redeem for payment 

2. Description of Related Art f rom me broker the scrip the vendor has collected. The 
Many information vendors on the Internet are accessed by vendor may of course make the redemption at a later time so 

consumers only once or twice for only small amounts of as to redeem scrip from multiple users, 

particular information at a time. To operate competitively, 25 This model is easily applied to token-based methods, and 

the information vendor must charge the consumer only a few j n these methods there is sometimes one additional 

cents for each access. Because of the small charge, the exchange: the vendor may make change, returning scrip to 

overhead in charging a consumer must be kept under tight the consumer equal to the amount tendered less the amount 

control. In addition, the method used to charge for the access charged. But the model also applies to account-based meth- 

raust verify that the consumer will pay. Early solutions to ods> In mc se methods, the scrip is usually simply credit-card 

these problems relied on using a central authority to verify information, and the broker is a credit card company. The 

access, slowing down the transaction. The challenge of difference is that in account-based methods, a consumer's 

keeping overhead low and providing rapid access persists. use 0 f scrip to pay for information is actually the exercise of 

There are essentially two approaches to the pay-per- 35 a pre-approved loan, 

access problem: token-based and account-based. Protocols i n a u D f these methods, the information vendor and the 

are built up around methods based on each of these consumer interface directly in the pay-per-access transac- 

approaches; a protocol, as used here, is a specific imple- { { on; the consumer sends a request for particular infor- 

mentation of a method of charging for a consumer's access mation with scrip to pay for it, and the vendor provides the 

to a vendor's information. ^ information. In doing this, the vendor ensures that the scrip 

In general, token-based methods have a consumer pur- is authentic by checking that the consumer has an account 

chase electronic tokens from a bank. To access a vendor's adequate to back the scrip. This requires either that the 

information, the consumer will pay the vendor using the consumer have an account with the vendor, or that the 

tokens. The vendor can then go to the bank and deposit the vendor get clearance to accept the scrip from a central 

tokens or redeem them for money. An account-based method 4S authority. There are three obvious difficulties with such 

works like a charge-card method of paying for merchandise. approaches: either a consumer must have a lot of accounts, 

A consumer authorizes a bank to transfer funds from the one with each vendor; or a central authority must be used for 

consumer's account to a vendor's account in exchange for each purchase, slowing the access and raising the transaction 

receiving information from the vendor. The funds transfer is cost; or, finally, every vendor must develop the capability of 

performed by the bank. 50 handling scrip, which may slow access, depending on what 

Token-based methods, compared to account-based the vendor must do with the scrip, 

methods, are generally considered to have the potential to What is still needed is a method of charging for each 

achieve lower transaction costs, but do not by themselves access in a way that is secure but fast, and that keeps 

meet the challenge of providing rapid on-line clearance. The overhead low. One way to do this is to involve the vendor 

account-based methods certainly meet the challenge of 55 as little as possible. The interactions that keep costs high or 

providing on-line clearance, but these kinds of methods slow access are those needed to ensure that a consumer's 

often lend to fall short in meeting the need for rapid access scrip is bona fide, 
at low cost. 

Protocols have been proposed by credit card companies SUMMARY OF THE INVENTION 

that essentially model the credit card system on the Internet. 60 The method of the present invention uses a third party, 

Because these methods use accounts identified by consumer called here a banker, as an agent for collecting a fee from a 

name, they fail in providing another desirable characteristic: consumer for browsing information provided over a network 

consumer anonymity. On the other hand, token -based meth- by a vendor. Before a consumer can request access to a page 

ods have been developed that do provide consumer ano- of information, the banker, after verifying that the consumer 

nymity. However, in both the token-based methods and 65 has credits on account to pay for the information, mints a 

account-based methods developed so far, overhead is usu- token that the consumer can use to pay for the information, 

ally too high to process transactions for which only a small The token can be used only by the particular consumer, for 
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a particular page of information. The banker keeps from the create a market without artificial barriers to entry, so that the 

consumer the network location of the information until the number of bankers and the capacity of existing bankers can 

consumer returns the token in exchange for the information. expand and shrink to accommodate market demand, and 

In one embodiment of this method, the interaction each banker can compete with the others for consumer 

between vendor and consumer is limited to the consumer 5 accounts by offering different services in addition to the 

retrieving the vendor-provided information from the vendor primary service of managing pay-per-access transactions, 

after the banker provides the consumer with the search data It is also an object of the present invention to keep 

required to retrieve the paid-for information. The banker overhead in charging for access low enough that charges as 

manages all other transactions needed to pay the vendor for small as Vioth of a cent are feasible, 

the information provided. This method is particularly suit- id It ^ another object of lhe present invention l0 provide a 

able where the network includes the Internet, and where the pay-per-access method in which the consumer's identity can 

banker provides the required search data to the user's be traced onIy through the banker. 

Internet browser. ^ ^ anot k cr ob j ect Q f me p rescn t invention to provide 

To make the information available for a charge, the active measures that prevent a vendor &om tricking a 

vendor creates a top commerce (Web) page having links to 15 consumer int0 paying more for a link than the co DSUmer 

Web pages the vendor wants to sell, and to any lower-level believes he is paying. 

commerce pages linked to the top commerce page. Each link T . - ,. ' c . . ... 

,j 4 - 4 , , , . M , c It is a further object of the present invention to provide 

uses an address to point to a lower-level Web page. Next, for J . . . . , , . 

0 , , _ K ^ t . „ nnA ~ n AA<. „ pay-per-access reqmnng no public key technology, or other 

each link on each commerce page, the vendor adds a field t * a rt hi t h 

that indicates the charge for accessing the linked Web page. 20 ^ ™ °S ra P v - 

Each of these links, now bearing a price for the linked Web li * anolher ob J ecl of the P resent invention to provide 

page, is called here a priced link. pay-per-access enabling automatic content screening so that 

To introduce the consumer to the top commerce page, the • consumer can block access to inappropriate information 

vendor also creates a front door. Hie front door is a Web from the f turner s network location, by, for example, the 

page that has an entry link, i.e. a link that ultimately accesses 25 consumer s children. 

for the consumer a personalized copy of the vendor's top BRIEF DESCRIPTION OF THE DRAWINGS 
commerce page, giving the consumer access to the pay-per- 
access Web pages linked directly to the top commerce page, The above and other objects, features and advantages of 
or linked indirectly through lower-level commerce pages the invention will become apparent from a consideration of 
that are themselves linked to the top commerce page. the subsequent detailed description presented in connection 

By exercising an entry link, such as by clicking on it, a with accompanying drawings, in which: 

consumer is connected to the banker, but kept from learning piG. la is a transaction diagram for pay-per-access meth- 

the secret the address of the top commerce page (at the ods according to the prior art* 

vendor Web site). Exercising the entry link prompts the 3J pjQ lb ta a transaction diagram for a pay-per-access 

banker to create a personalized copy of the commerce page, method lccotdi to the , mvention; 

and to provide it to the consumer. Before providing the . 

personalized copy of the commerce page to the consumer, F J G ' 2 15 » process flow diagram for a pay-per-access 

however, the banker alters each priced link by redirecting it method ac c°^ing to the present invention; 

to point to the banker, instead of to the vendor, and by FIG. 3 is a representation of linked pages on the World 

attaching a token to it. The priced link is then said to be 40 Wide Web, showing ordinary links and tokenized links; 

tokenized. Each token conveys all the information the FIG. 4a and FIG. 4b illustrate an aspect of the method of 

banker needs to both provide the consumer with, and charge the present invention in a case where a consumer and a 

the consumer for, the pay-per-access information associated vendor have accounts with different bankers; and 

with the tokenized link. 45 piG. 5 is an illustration of an aspect of the method of the 

The method of the present invention is not confined to a present invention in a case where a vendor collects tokens 

particular protocol; for example, it is not limited to a directly from a user, 
particular set of modifying fields, nor is it limited to a 

particular manner of embedding fields in an Internet address. BEST MODE FOR CARRYING OUT THE 

In addition, the method of the present invention is not 5Q INVENTION 

confined to use on the Internet. The essential concept that of ^ fcrred embodinjeDt of tl)6 , jnvention fc as 

a third-party for minting secure tokens for particular pay- a me , h £ d for . for information F at , Web site of , he 

per-access transactions, has general utility, and can be imple- Worfd wide Web acc6Sscd Qvef ^ Imernet 

mented in many ways and for many different applications, as Some Terminology 

will become apparent to one skilled in the art. 55 In ^ description> a document ^ a page of information 

It is an object of the present invention to provide a means lhal a vendor charges lo access . a documen t is located at a 

of pay-per-access that requires no additional software or Web sitC) usually that of the vendor charging for access t0 

hardware for either vendors or consumers. the document . A page at a Web site can bear information for 

It is a further object of the present invention to provide w hich a charge is made, or can serve other purposes, such as 

pay-per-access in a way that can be implemented without 60 presenting to a consumer a menu from which to select a 

using hypertext commands, electronic wallets, bank cards, document. A consumer is one who views a document on the 

or other plug-ins or hardware. world Wide Web, called the Web from here on, by accessing 

It is further an object of the present invention to provide the document over the Internet. A link is a part of a document 

tokens that are minted only as needed and are good only for that a consumer can click on, i.e. exercise, to access a related 

a specific transaction in a specific time frame. 65 document. A tokenized link is a link that when clicked on 

It is another object of the present invention to provide a causes not only the linked document to be displayed to the 

method that permits any facility to become a banker, i.e. to consumer, but also results in the consumer being charged a 
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fee for the document, and the vendor being paid a fee. The issues the vendor a page-ID for the top commerce page so 

fee is paid by the consumer in credit units; the vendor is paid that the top commerce page can be publicly referenced later 

with money; here, the term credit units is used in a generic without revealing its actual Web address (which is at the 

sense to indicate a data object representation of money, i.e. vendor's Website), 

a kind of scrip. However, a consumer uses a token to convey 5 Embedding Tokenized Links 

credit units. After establishing an account at a banker, a vendor places 

Tokens, which are data objects having a specific value in in the Web page to be used as a top commerce page one or 

credit units, are minted by a banker for use in purchasing more links each pointing to a pay-per access page and 

access to a particular Web page, charging an account of a conveying a cost for access (step 23c of FIG. 2). Although 

particular consumer and crediting an account of a particular 10 other syntax is possible, in the preferred embodiment an 

vendor, usually the vendor that owns the Web page. A banker ordinary html Web page is made into a commerce page by 

is any Web-based authority that mints tokens using a pro- appending a cost field to a link. For example, if the com- 

tocol based on the present invention and exchanges spent merce page has a link, 
tokens for credit units, which can then be exchanged for 

ordinary money. A commerce page is a page that includes 15 http://www.vendor.com/ncws.html 

one or more tokenized links. A tokenized link is a link with ^ f[)r it t0 be d as a riced Hnk costin n ^ the 

an embedded token; exercising a tokenized link, by for yendor WQuld ch the ^ iQ 
example clicking on it, uses the token, which results in 

access to the particular information for which the token was http://www.vcndor.com/ncws.htm]?cost=7a. 

minted. There is no charge for accessing a top commerce 20 

page, i.e. the commerce page uppermost in the vendor's In other svntax ' the ^ field mi ^ x be added at P laces olner 

linked hierarchy of pages grouped for a pay-per- access than the end of a ^ the onl y limitation is that the link be 

service. parseable. 

In addition to the terminology specific to the present with tne action of the cost field to a link, the Web page 
invention, this description uses some standard terminology 25 Wlth the hnk becomes a commerce page, and the link 
associated with Web documents and transport protocols. becomes a priced link. Until it is later tokenized by a banker, 
Hypertext markup language (html) is a format used by most a P riced ^ P oinls directl y t0 the pay-per-access page at the 
documents on the World Wide Web. A uniform resource vendor's Web site. The vendor might also place priced links 
locator (URL) is a Web address, which uniquely identifies in lower-level Web pages, making those pages both com- 
the location of a particular document (information -bearing 30 merce P^ and pay-per-access Web pages. These lower- 
page) on the network. A hypertext transfer protocol (http) is level commerce pages would then point to information- 
the standard protocol used to retrieve and view Web docu- bearin S P a S es even lower in the hnked hierarchy set up by 
ments. A common gateway interface (cgi) is a Web object the vendor - If the vendor waDts > a lower-level commerce 
that when referenced executes a program at a destination 030 XVfC onl y as a menu > instead of als0 bearin & 
address, and returns some data or a program-generated html 35 pay-per- access information, and the vendor can set the 
document. An extended URL (also called a cgi-extended char S e to access thc lower-level menuK)nly commerce page 
URL) is a Web address that is said to be extended because t0 2610 ( M mdced the char S e for an V Web P a S c 0311 bc sct t0 
of having data used as input by a cgi program at a destination zero), 
address. An example of an extended URL is Creating a Front Door 

40 The vendor must also create a Web page the consumer can 

http://www.sitc.c»m?data=399i77239l. access as a front door to the vendor's store of pay-per-access 

Setting Up Accounts Web P a & es ( ste P 23d of FIG. 2). The front door leads to a top 

Referring now to FIG, lb and FIG. 2, a consumer 14 commerce page, and is needed because the address of the top 

establishes an account with a banker 12, receiving a con- commerce page must be kept secret from the public, forcing 

sumer password so that the banker can positively identify 45 access through a banker. The vendor does this simply by 

the consumer (step 22a of FIG. 2). To open the account, the crealin g a Web P a S e wilh a link lhal direcls a consumer to 

consumer visits the banker Website, and uses a credit card, a banker > which enables the banker t0 men P re P are a 

for example, to purchase credit units according to some personalized copy of the commerce page for the consumer, 

exchange rate geared to allow one credit unit to be worth a For example, to direct a consumer, through a banker, to a 

fraction of a monetary unit, e.g. a fraction of a U.S. penny so vendor's commerce page assigned pageid equal to 51391009 

(step 22b of FIG. 2). The purchased credit units are then kept bv the banker > the vendor could edlt an ordinarv link > 

by the banker in an account for the consumer. In another makin g n & c (cgi-extended URL) entry link: 

embodiment, the consumer could be given credit, instead of http://www.bankcr. ro in/comm«cc?pagcid-5i39i009. 
being required to purchase a specific number of credit units; 

then the consumer could be billed later for credit units 55 Here, commerce is a cgi program, at the banker Web site, 

expended. that executes when the consumer clicks on the entry link; 

An information vendor 13 also opens an account with the commerce uses pageid-5 139 1009 as a parameter. The pro- 
banker 12 by visiting the banker Website (step 23a of FIG. gram commerce will tokenize the links of the top commerce 
2). When the vendor opens an account, the banker provides page, in the sense explained below, enabling the consumer 
the vendor with an identification the banker can later use to 60 to purchase information by exercising the tokenized links, 
positively identify the vendor. After opening an account, the Preparing a Commerce Page for a Consumer 
vendor can make information available to consumers for a Referring now to FIG. 3 and also to the transaction 
charge for each access collected by the banker at the time of processing branch of FIG. 2, a pay-per-access begins when 
access. To allow for this, the vendor specifies the Web a consumer clicks on an entry link of a front door Web page 
address of a Web page he will use as a top commerce page, 65 31, causing execution of a secure program at a banker 33a 
which includes tokenized links to the pages the vendor with a parameter that the banker uses to both look up the 
wants to sell access to (step 23b of FIG. 2). The banker address of the commerce page to access, and to identity the 
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vendor (step 24a of FIG. 2). (The symbol C 24aib of 33a of 
FIG. 3 indicates the banker is performing steps 24a and 24b 
of FIG. 2.) The secure program advises the consumer that 
the page being accessed includes priced links, and requests 
the consumer's bank account password. For convenience, 
the consumer's bank account password could be entered 
automatically using a browser plug-in program, although 
this is not necessary. 

After the banker 33a verifies the consumer's bank account 
password, it looks up the secret address of the commerce 
page, and retrieves a copy of the commerce page, either a 
fresh copy via ftp/http/bttps, or a cached copy. Next, it 
tokenizes all priced links on the commerce page, which 
readies these links for use by the consumer (step 24b of FIG. 
2). To tokenize a link, the banker computes a token for the 
transaction associated with the priced link, and replaces the 
priced link with a link that instead sends the token to the 
banker for processing. For example, the priced link, 

http://www.ve ndor.corrVnews. htm l?cost=71 

would be replaced with 

http://www.bantcr.com/link7tokcn, 

where token is a data object banker uses to charge a 
consumer and credit a vendor account for a pay-per-access, 
A token is computed as described below in a way that 
encodes several items of transaction-related information, 
including at least the amount the consumer should be 
charged for the information, the consumer identification, the 
vendor identification, and the address of the destination 
pay-per-access Web page. 

After tokenizing the priced links on the commerce page, 
the secure program forwards the commerce page to the 
consumer; this transfer can advantageously be done via 
https. Throughout all this the network location of the com- 
merce page remains hidden, because the document was 
forwarded from the banker. Also, at no point thus far has 
there been a charge to the consumer, because the consumer 
has yet to exercise a tokenized link; the consumer has so far 
clicked only on the entry link. Upon viewing the top 
commerce page, the consumer may decline to purchase any 
information from the vendor, and there would then be no 
charge to the consumer. 
Making a Sale 

With tokens embedded in links on a commerce page, if a 
consumer clicks on one of the tokenized links, the banker 
will decipher the embedded token. In one embodiment of the 
present invention the token may include, among other fields, 
a signature indicating that the token was in fact issued by the 
banker, a time-stamp verifying that the token is not too old 
according to some predetermined allowable time period for 
using the token, and the number of credit units charged for 
the information. After deciphering the token, which will 
provide the banker with all data needed to handle the 
transaction for which the token was computed, the banker 
will direct the consumer's browser to the information- 
bearing, paid -for Web page at the vendor's site. In decipher- 
ing a token, the banker examines it for tampering and 
obsolescence (a token is issued to be good for only a short 
time), and then extracts the transaction data it needs for 
charging the consumer account and crediting a vendor 
account (usually the vendor who owns the information- 
bearing Web page being accessed). 

In another embodiment, the banker protects the consumer 
by modifying the commerce page to indicate precisely 
which links are tokenized links by adding a price tag image 
to each hyperlink that is in fact a tokenized link. 
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In the case of linking from a commerce page 32 (FIG. 3) 
to another commerce page 36, after performing step 24c 
(FIG. 2) the banker will restart transaction processing 
• according to step 246, retrieving the commerce page, autho- 
. rizing all the valid tokenized links, and forwarding the page 
to the consumer. In linking to a pay-per-access page 34 from 
commerce page 32, since there are no tokenized links on the 
pay-per-access page, the banker 33b will perform first step 
24c of the transaction processing branch, i.e. it will transfer 
the cost from the consumer to the vendor, and then step 24b, 
directing the consumer's browser to the Web address asso- 
ciated with the tokenized link. 
More Commerce Page Syntax 

By default, revenue for all tokenized links goes to the 
vendor identified by the pageid for the top commerce page. 
However, a vendor could indicate that payment be directed 
to another vendor by simply adding a vendor field, as for 
example in: 

http://www. vendor.com/news. htm I ?oost-71&vendor-66100 12. 

Here the standard syntax is used for extending URLs. The 
question mark character precedes the data, and data 
items are separated by the ampersand character "&". Other 
fields used in the preferred embodiment are shown below in 
Table 1. 

TABLE 1 



Field 



Fields available to a vendor for use in tailoring a tokenized link 
Description 



cost cost of a link in credit units 

vendor identification of vendor to be credited 

hop indicates a link leading to another commerce page, a kind of 

link requiring, in one embodiment, that the identities of the 

consumer and vendor be preserved 
35 resell specifies a percentage of each tokenized link transaction a 

vendor will pay as a commission to another vendor who 

refers a consumer to a top commerce page 
reseller specifies the vendor identification of the referring vendor 
suitability indicator of suitability for children 
reverse indicates that the direction of the transaction should be 
40 reversed, i.e. that the transfer of credit units at the banker is 

to be from the vendor to the consumer (used for granting 

refunds) 



Computing Tokens 

According to the present invention, a token is a data 
object used by banker to charge a specific consumer for 
accessing a specific Web document for a specific charge. In 
the preferred embodiment, a token includes the data fields 
shown in table 2, where the period indicates concatena- 
tion of the strings that are the values of the different fields. 



45 



50 



55 



60 



TABLE 2 



Field 



Data fields included in a token 
Description 



time seconds since jan. 1, 1970 (standard UNK timestamp) 

consumer consumer account number 

vendor an identification of a referring vendor 

cost cost for the access (in terms of credit units) 

target address of document to be accessed (enciphered) 



65 



From these data fields, the banker constructs a concatenated 
transcode field: 

transcode=time.consumer.vendor. cost, target 

In addition to the data fields, a token includes a control 
variable globalCV, which is, in the preferred embodiment, a 
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64-hexadecimal-digit, private cryptovariable provided by After tokenizing each link on the commerce page, the 

the vendor's banker. With the control variable and the data consumer's banker forwards it to the consumer. This enables 

fields, the banker constructs a 64-hexadecimal-digit, public the consumer to exercise a tokenized link, by clicking on it 

signature of the token, according to: for example, prompting the consumer's banker to process 

5 (unwrap) the token it minted, charge the consumer and credit 

signature-hashCtmnscode.giobaicv) the vendor » s accourjt) and then redirect the consumer to the 

where hash ( ) indicates any irreversible encipherment vendor's badcer. In redirecting the consumer to the vendor's 

algorithm, i.e., any procedure that computes a digital sig- * he consumer » banker conveys to the vendor's 

nature for a document so that tampering can be detected. ^ ke [ th f token minIed b * the vendor s banken ? e vea " 

Finally, the banker computes the token by concatenating the 10 d ° r ' s banker unwra P s lts l u oken ' and > bas f d on the flelds the 

signature with the transcode according to: token contains, redirects the consumer's browser to the now 

paid-tor information. At the same time, the vendor's banker 

token-transcode.signature. will credit the vendor's account for the access. Later, it may 

withdraw from its account with the consumer's banker the 

If a vendor places other data fields in a link, such as hop or 15 orecJIt units deposited there by the consumer's banker when 

resell, they are also included in the transcode. the consumer's banker charged the consumer for the access. 

When a Consumer Account Falls Short An Embodiment Where the Vendor Collects Tokens 

In the preferred embodiment, whenever a consumer exer- Referring now to FIG. 5, in another embodiment of the 
cises a particular tokenized link on a commerce page, and present invention, a vendor 52 collects tokens from a con- 
then backs up from the linked page to the same commerce 2 o sumer 53, instead of a banker collecting the tokens. A banker 
page, the banker refreshes the commerce page by again entity 51, which might be both the vendor's banker and the 
tokenizing the links. That way the consumer can be charged consumer's banker acting in cooperation as explained 
again for re-accessing the same information. aDO ve, only mint the tokens for a commerce page, embed 

If some of the tokenized links on a commerce page cost them in the commerce page, and provide the commerce page 

more than the consumer has on account, but the consumer 2 5 to the consumer. In this embodiment, the location of the 

can afford some of the other tokenized links, the banker will vendor's information is still kept secret from the consumer 

mint the tokens the consumer can pay for. If, after accessing unt n me consumer pays for the information using a token, 

a pay-per-access page, the consumer backs up to the same j 0 prepare the vendor to accept tokens, the banker entity 

commerce page, the banker will again tokenize the links 51 provides the vendor with franking software and a 64-bit 

according to the same procedure as before. 30 vendor cryptovariable, specific to the vendor. When the 

When a Consumer and Vendor Use Different Bankers consumer 53 exercises a tokenized link, the vendor 52 franks 

Referring now to FIGS. 4a and 4b, when a consumer 44 lhe tokeri) i-C- tests t0 determine if the token is counterfeit, 

and vendor 41 have accounts at different bankers, the if the token is bona fide, the vendor deciphers the token to 

consumer's banker 43 and the vendor's banker 42 cooperate determine the location of the information the token buys, 

in enabling the consumer to access the vendor's information. 35 redirects the consumer to the information, and stores the 

After the consumer clicks on an entry link at the vendor's token ^ that it can redeem it later with the banker entity. 

Web site, the vendor's banker retrieves a copy of the In the preferred embodiment of implementing this aspect 

vendor's top commerce page and attempts to tokenize its 0 f the invention, two additional fields are used in computing 

priced links. When the vendor's banker discovers that the tokens; they are shown in table 3. 

consumer does not have an account with it, it asks the 40 

consumer what banker to use. Assuming the consumer has TABLE 3 

an account with some other banker, the consumer provides 

the vendor's banker with account information the consumer Data fields included in a token to be collected by a vendor 

has with another banker. The vendor's banker then tokenizes Descri t on 

the priced links on the top commerce page and forwards the 45 Fie d Description 



page to the consumer's banker. The consumer's banker then vendorCV 64 random bits, a cryptovariable used to identify a vendor to 

also tokenizes the now already once tokenized links. a banker 

In Other words, the vendor's banker takes a priced link ^target target enciphered using vendorCV 

from the top commerce page, such as 

50 In tokenizing a priced link, in place of token computed as 

http : //www.vendor.conVnewB.html?cost-7i described above, a banker would use 

and replaces it with a token it computes, so that it becomes, mtoken=token.mtarget.msignature 
for example, 

where 

http;//www.banker-vendor.com/link-vendor?token-vendor, 55 

msignature=hash(token.vendorCV). 

where token-vendor includes the un-enciphered cost (in ,„ additi , he baQker wou , d ch , he URLof ^ ^ w 

credit units) in as transcode element so .bat the consumer s , hal tfae , oken fa de , ivered (0 ^ yendor>s ^ 

banker can read the cost The vendor s banker then forwards inslead of , Q the bankef , n lhe case of h howeve B (he 

the commerce page to the consumer s banker, which then 6Q banker ^, irected format described above fe used for lokeo . 

replaces each once-tokenized link with a link bearing a ^ a rfced ^ DQt lhis yeadol .<ii Ka «i format. In this 

token the consumer s banker ra.nts. Such a doubly embod iment a vendor can now frank arriving tokens, extract 

tokenized link could look like, , he ne(work of , he information purchased by lhe 

hiip : //ww.banker-con S umer.comyiink-consumer?ioken-coiisunier, loken > and redirect the consumer to the information. This 

65 franking is accomplished without breaching token integrity, 

in which token-consumer encapsulates the token minted by without resort to public-key operations, and without involv- 

the vendor's banker. ing a banker. 
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All of the embodiments disclosed here rely on the core 
feature of the present invention — using a third-party as a 
toll-gate to control access by a consumer to a vendor's 
information. It is to be understood that the above -described 
arrangements are only illustrative of the application of the 
principles of the present invention. Numerous modifications 
and alternative arrangements may be devised by those 
skilled in the art without departing from the spirit and scope 
of the present invention, and the appended claims are 
intended to cover such modifications and arrangements. 

What is claimed is: 

1. A method of charging a consumer for access, over a 
network, to at least one page of information provided by a 
vendor at a network site, the method using a third-party 
acting as a banker for transferring funds associated with said 
charging from the consumer to the vendor, the consumer 
having a quantity of credit units on account with the banker, 
the vendor having an account with the banker for holding 
credit units that the banker collects from consumers, the 
vendor having a page accessible over the network to the 
public that includes a link to a program at the banker and a 
parameter for the program, the parameter for identifying 
another network page of the vendor in a way that enables the 
banker to access a copy of the other network page, the other 
network page having links to lower-level pages that the 
vendor charges consumers to access, the method executed 
when a consumer exercises the link on the page accessible 
to the public, the method comprising having the banker 
obtain a copy of the other network page of the vendor, and 
alter on the page the links to lower-level pages, the links to 
the lower-level pages indicating a charge in credit units for 
access to each linked page, said altering including the steps 
of: 

a) minting a token for each page of linked information, the 
token encoding all of the data the banker needs to 
charge the consumer for accessing said linked page of 
information; 

b) redirecting each link to the banker site and embedding 
in each redirected link the token for the linked infor- 
mation; and 

c) also embedding in each redirected link instructions for 
the banker that if the consumer clicks on one of the 
links, the banker Ls to execute a program for charging 
the consumer account for the access in credit units, 
crediting the vendor account, and directing the con- 
sumer to the linked information without identifying to 
the consumer the network location of the linked page of 
information, 



15 
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35 



whereby the consumer accesses a page of linked infor- 
mation only after paying for the information with a 
token, and without learning the network location of the 
linked page of information. 

2. A method as claimed in claim 1, further comprising the 
step of determining which pages of information the con- 
sumer has enough credit units on account to pay for. 

3. Amethod as claimed in claim 1, wherein the third-party 
comprises a banker holding an account of the vendor and a 
different banker holding an account of the consumer, 
wherein the vendor's banker has an account with the con- 
sumer's banker, wherein the altering, on the other network 
page of the vendor, the links to lower-level pages is per- 
formed first by the vendor's banker, creating once-altered 
links, and wherein the method further comprises the steps in 
which the consumer's banker: 

a) determines which pages of information the consumer 
has enough credit units on account to pay for; 

b) mints a token for each page of linked information, the 
token encoding all of the data the consumer's banker 
needs to charge the consumer for accessing said linked 
page of information; 

c) redirects each link to the consumer's banker site and 
embeds in each redirected link the token for the linked 
information; and 

d) also embeds in each redirected link instructions for the 
consumer's banker that if the consumer clicks on one of 
the links, the consumer's banker is to execute a pro- 
gram for charging the consumer account for the access 
in credit units, crediting the vendor's banker's account, 
and directing the consumer to the vendor's banker. 

4. A method as claimed in claim 1, wherein, when the 
consumer exercises a link to a lower-level page requiring a 
token to access, the vendor's banker collects the token from 
the consumer, determines if the token is valid, and, if so, 
directs the consumer to the lower-level page. 

5. A method as claimed in claim 1, wherein, when the 
consumer exercises a link to a lower-level page requiring a 
token to access, the vendor collects the token from the 
consumer, determines if the token is valid, and, if so, directs 
the consumer to the lower- level page. 
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POLYMORPHIC DATA STRUCTURES FOR 
SECURE OPERATION OF A VIRTUAL CASH 
SYSTEM 

This invention relates to a combination of methods which 5 
together implement a system for the electronic transfer of 
value combining the anonymity and decentralized nature of 
cash transactions with the security and fraud -resistant fea- 
tures of credit card transactions. 

10 

BACKGROUND 

Systems for transferring value have evolved in two direc- 
tions. In one direction, represented by credit cards, each 
value-transferring transaction is individually authorized 
online by a centralized clearinghouse and recorded at the 15 
time of the transaction. Authorization typically consists of 
verifying whether the account number read from the card 
has sufficient credit to engage in the proposed transaction. 
These systems are typically usable for a broad variety of 
transactions involving different vendors. In the other 20 
direction, represented by prepaid phone cards or subway 
tickets having a remaining value encoded on a magnetic 
stripe, there is no record of individual transactions. Inspec- 
tion is performed off-line without a central clearinghouse by 
verifying that sufficient value for the transaction is physi- 25 
cally encoded on the card. These systems typically can be 
used for transactions involving only a limited number of 
vendors. 

Recently, "smart cards" having a microprocessor embed- 
ded in the card have been developed. These permit a variety 30 
of accounts to be encoded on a single card. This permits 
value to be added to as well as removed from a variety of 
accounts. A smart card is therefore typically equivalent to a 
plurality of one of the cards described above. 

A recent innovation is the Mondex card used to create an 
electronic form of currency. A system using the Mondex 
card permits a user of the system to transfer a data packet 
representative of cash to another user of the system in such 
a way that the recipient of the data packet can transfer it 4Q 
again to yet another user of the system, for value, or to a 
bank, for credit to an account. Unlike the credit card systems 
described above, the Mondex system permits transactions to 
take place off-line without the intervention of any central- 
ized clearinghouse. Unlike the debit card systems described 4S 
above, the cash equivalents circulating in a Mondex system 
can be used to pay a variety of different vendors. 

The Mondex system falls short of implementing a true 
replacement for physical cash. In the Mondex system, cash 
is never actually minted. It is merely recognized as value 50 
being deposi table in a bank. In addition, security is limited 
and rudimentary. There exists no effective way to authenti- 
cate the circulating data packets and to detect counterfeits. 

There exists a need, therefore, for a system of circulating 
data packets representative of cash in which an authentica- 55 
tion mechanism reliably detects counterfeit data packets. 

SUMMARY 

The present invention provides for a secure system for 
circulating a data packet representative of a cash note 60 
between a plurality of terminals. The system includes meth- 
ods for creating and destroying the data packet and methods 
for negotiating the data packet from a transferor terminal to 
a transferee terminal in a secure manner. As part of the 
negotiation process, the system provides a method for peri- 65 
odically inspecting the data packet to assure its authenticity 
and its integrity. 
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The data packet representing the cash note can exist in one 
of two circulation states. In the non-circulating state, transfer 
of the data packet from one terminal to another is restricted. 
In the circulating state, the data packet can exist in one of 
two inspection states: an inspected state, in which it can be 
freely transferred from one terminal to another, and an 
uninspected state in which transfer from one terminal to 
another is restricted. 

The data packet includes an encrypted record permanently 
associated with the note and a cleartext record which can be 
altered by the terminal having possession of the data packet. 
It is by suitably altering the cleartext record that a terminal 
changes the inspection state or the circulation state of the 
data packet. 

The encrypted record includes a serial number, which 
uniquely identifies the data packet, and an original face 
value, which indicates the denomination of the cash note. 
Additionally, the encrypted record can include means to 
identify the creator of the data packet and means to identify 
the terminal requesting the data packet. A private key is used 
to encrypt the encrypted record. 

The cleartext record contains a field identifying the 
inspection state of the data packet, a field specifying the 
current face value of the data packet, and, optionally, a field 
specifying the circulation state of the data packet. In the 
inspected state, the cleartext record includes a key which can 
be used by a transferor terminal to generate a signature 
corresponding to that key. In the uninspected state, the 
cleartext record includes the signature generated by the 
transferor terminal using the key. 

A record of the existence and status of a data packet is 
stored in a validation database. This validation database is 
updated during the lifetime of the data packet to reflect 
changes such as changes in inspection status, circulation 
status, or in the value remaining in the data packet. 

The system includes five types of transactions. These 
transactions differ in the changes made to either the circu- 
lation state or the inspection state of the data packet. The five 
transactions are: 

minting, which includes generating the data packet's 
encrypted record and attaching to it a cleartext record 
which places the data packet into a non-circulating 
state; 

withdrawing, which includes altering the cleartext record 
to place the non-circulating data packet into a circulat- 
ing and inspected state; 

negotiating, which includes altering the cleartext record to 
place the circulating and inspected data packet into an 
uninspected state; 

inspecting, which can include, if the data packet passes 
inspection, altering the cleartext record to place the 
circulating and uninspected data packet into an 
inspected state 

depositing, which includes altering the cleartext record to 
place the circulating data packet into a non-circulating 
state. 

The system includes five types of terminals which differ 
in the types of transactions they can engage in. These are: 

central banks, which can mint data packets and which 
maintain validation databases of data packets in circu- 
lation; 

account custodians, which can change the circulation state 

of a data packet and which can restore an uninspected 

data packet to its inspected state; 
personal terminals, which can change a data packet from 

being in an inspected state to being in an uninspected 

state; 
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home-based terminals, which, by communicating with an 
account custodian, can restore an uninspected data 
packet into its inspected state; and 

vendor terminals, which can place the data packet into an 
uninspected state, and which, by communicating with 
an account custodian, can restore the data packet into 
its inspected state. 
Minting 

Minting is the process of creating a data packet represen- 
tative of a cash note. The process of minting is typically 
performed by a central bank terminal at the request of 
another terminal, typically an account custodian. The 
account custodian usually specifies the cash value of a data 
packet to be minted. The central bank then checks the 
account custodian's credit. If the account custodian's credit 
is deemed satisfactory, the central bank creates the data 
packet by assembling the parts as described above. The 
central bank then updates a database to indicate that it has 
created a new data packet. 

The new data packet, in a non-circulating state, is then 
transferred to the requesting account custodian. 
Withdrawing 

Withdrawing a data packet is accomplished by having a 
cash data packet transferred from a dispensing terminal to a 
withdrawing terminal. Normally, the dispensing terminal is 
an account custodian or a terminal in communication with 
an account custodian, such as a home-based terminal. 

The dispensing terminal alters the cleartext record of the 
data packet to be withdrawn in order to place it into a 
circulating state and into an inspected state. The data packet, 
now in a circulating and inspected state, is transferred to the 
withdrawing terminal, typically a personal terminal. 
Negotiating 

During negotiation of the cash data packet, the transferor 
terminal, usually a personal terminal, alters the cleartext 
record of an inspected cash data packet, thereby placing it in 
an uninspected state, and transmits it to a transferee termi- 
nal. The cash data packet will then exist in the transferee 
terminal, most often another personal terminal, in an unin- 
spected state. 

Because a data packet is negotiable only in its inspected 
state, the transferee terminal will not be able to negotiate the 
data packet to another terminal until an inspecting terminal 
inspects the data packet in the manner described below and 
restores it to its inspected state. 

As is often the case in cash transactions, the purchase 
price of the good may not correspond to the inspected data 
packets, either singly or in combination, available to pay for 
the goods. Under these circumstances, it becomes necessary 
to subdivide the data packets, thereby making available a 
combination of data packets having a denomination corre- 
sponding to the purchase price of the goods. This process, 
commonly referred to as "making change," is a feature of 
another embodiment of the invention. 

To make change, the data packet representative of a cash 
data packet is duplicated into a first data packet to be spent 
and a second data packet to be retained. The value of the data 
packet to be spent is set to the purchase price of the goods. 
The value of the data packet to be retained is set to the value 
of the data packet prior to the transaction less the purchase 
price. Both the data packet to be spent and the data packet 
to be retained have the same encrypted record. The data 
packet to be spent is then negotiated in the manner set forth 
above. 
Inspecting 

During inspection of the cash note, the terminal request- 
ing inspection, for example a personal terminal, transfers the 
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note to an inspecting terminal, which could be an account 
custodian. The inspecting terminal decodes the transferor's 
signature from the note's cleartext record to recover its 
corresponding key. This enables the inspecting terminal to 

5 recover the note in the form it was in before the transferor 
terminal transferred it. The inspecting terminal can then 
compare the recovered note against a copy of the note as 
stored in a validation database of circulating notes main- 
tained by a central bank terminal. If the stored copy of the 

id note is consistent with that presented for inspection, the 
inspecting terminal alters the cleartext record of the note to 
place it back in the inspected state and sends the inspected 
note back to the terminal requesting the inspection. The 
inspecting terminal then causes the validation database of 

15 circulating notes to be updated with the inspected note so 
that a copy of the note will be available when that note is 
next presented for inspection. 
Depositing 

A depositing terminal, typically a personal terminal or a 

20 vendor terminal, can also deposit the note, for credit, into an 
account at a financial institution. It does so by transferring 
the note to a terminal in communication with an account 
custodian, or to the account custodian itself. In one 
embodiment, the depositing terminal is a personal terminal 

25 which transfers the note to a home-based terminal in com- 
munication with an account custodian. In another 
embodiment, the depositing terminal is a vendor terminal 
which transfers the note directly to an account custodian. 
Upon receipt of the note to be deposited, the account 

30 custodian causes the note to be removed from circulation, 
causes the database of circulating notes to be updated to 
reflect the removal of the note from circulation, and causes 
the depositing terminal's account to be credited by the 
amount shown as the current face value of the note being 

35 deposited. 

These and other features, aspects and advantages of the 
invention will be better understood with reference to the 
following description, the appended claims, and the accom- 
panying drawings in which: 
40 FIG. 1 shows a data packet in its inspected state; 

FIG. 2 shows the data packet of FIG. 1 in its uninspected 
state; 

FIG. 3 shows the overall circulation of the data packet of 
FIG. 1 as it makes its way from a minting central bank, to 
45 a consumer carrying a personal terminal who then purchases 
an item from a vendor by using the vendor's vendor termi- 
nal; 

FIG. 4 shows the overall circulation of the data packet in 
FIG. 1 with the additional step of negotiation from one 
50 personal terminal to another, 

FIG. 5 shows two ways in which the data packet of FIG. 
1 can enter circulation; 

FIGS. 6A-6C show the steps by which an inspected data 
packet as shown in FIG. 1 is negotiated from one terminal 
55 to another, thereby turning it into the uninspected data 
packet of FIG. 2; and 

FIGS. 7A-7B show the steps by which the uninspected 
data packet of FIG. 6C can be restored to an inspected state. 

60 DESCRIPTION 

A data packet representative of a cash note to be used in 
a system embodying the invention can exist as an inspected 
data packet 100, as shown in FIG. 1, or as an uninspected 
data packet 110 as shown in FIG. 2. In both its inspected 
6S state and its uninspected state, the data packet includes two 
parts: an encrypted cash serial number 10 which remains the 
same for the life of the data packet; and a cleartext or 
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unencrypted section whose contents depend on whether the 
data packet is in an inspected state or an uninspected state. 
The cleartext portion switches between being a validation 
check number 20 when the data packet is in an inspected 
state, as shown in FIG. 1, and a transfer authorization 5 
number 30 when the data packet is in an uninspected state, 
as shown in FIG. 2. 

Referring to FIG. 1, the encrypted cash serial number 10 
includes a denomination field 12 indicating the original 
value of the cash note represented by the data packet and, 10 
optionally, the currency used to measure that value. The cash 
serial number 10 can also include a central bank identifica- 
tion field 14 identifying when and where the data packet was 
minted. This central bank identification field 14 may 
include: a central bank identification number 14a uniquely 15 
identifying the central bank which minted the data packet; a 
minting time stamp 14b showing the date and time that the 
data packet was minted; and a central bank sequence number 
14c which can be incremented by the central bank to further 
identify the data packet. 20 

The encrypted cash serial number 10 can also include an 
account custodian identification field 16 to identify the 
account custodian that requested the minting of the data 
packet. The account custodian identification field 16 can 
include: an account custodian identification number 16a 25 
uniquely identifying the account custodian requesting the 
data packet; a requesting time stamp 16b indicating the date 
and time at which the account custodian requested minting 
of the data packet; and an account custodian sequence 
number 16c which can be incremented by the account 30 
custodian. 

In the inspected state, shown in FIG. 1, the unencrypted 
section of the data packet has a validation check number 20 
which includes: an inspection check number 24, which is an 35 
arbitrary number assigned by the central bank upon minting 
the data packet; a remaining value field 22, which indicates 
the value remaining in the data packet and which is always 
less than or equal to the value shown in the denomination 
field 12; and a transfer authorization key 26 which is a 4Q 
random number used to convert a data packet in an inspected 
state into a data packet in an uninspected state in a manner 
to be described below. 

The validation check number 20 can also include a 
circulation field 36 for specifying whether the data packet is 45 
in a circulating state or in a non -circulating state. In the 
preferred embodiment, the most significant bit of the 
remaining value field 22 is used as the circulation field 36 of 
the data packet. 

FIG. 3 shows one possible life cycle of a data packet as 50 
it circulates through the stream of commerce. In FIG. 3 an 
account custodian 42 maintains an inventory of data packets 
having various denominations for withdrawal by a personal 
terminal 44. When the number of data packets having a 
particular denomination falls below a predetermined 55 
threshold, software running on the account custodian for the 
purpose of monitoring the inventory of data packets triggers 
a request for additional data packets. The account custodian 
42 then transmits the request for data packets to a central 
bank 40. In response to this request, software executed by 60 
the centra] bank 40 mints the requested data packets and 
transmits them to the account custodian 42. The central bank 
also executes software instructions to create an entry in a 
validation database 43 corresponding to the data packet. The 
account custodian holds each data packet in non-circulating 65 
and uninspected form in memory until a personal terminal 
44 requests a data packet. 
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The personal terminal's request for a data packet can 
originate when a human operator brings the personal termi- 
nal 44 into communication with an account custodian 42 and 
specifies the number and denomination of data packets to the 
personal terminal through its user- interface. Communication 
between the personal terminal and the account custodian can 
be effected by a telephone or by other cable linking them. 
Communication between the human operator and the per- 
sonal terminal 44 can occur by providing the personal 
terminal with a menu system or pointing device, by provid- 
ing it with a keyboard or keypad which can have predefined 
keys for common functions, or by leading the human opera- 
tor through a transaction with on-screen instructions pre- 
senting options which can be chosen by means of a 
keyboard, keypad, or pointing device. In response to the 
human operator's request, the personal terminal 44 then 
transmits a message representative of the request to the 
account custodian 42. 

Upon receiving a request from the personal terminal, 
software running on the account custodian 42 fetches a data 
packet from memory and alters the circulation field 36 to 
indicate that it is now in a circulating state. The account 
custodian then transmits the data packet to the personal 
terminal 44. 

The next step occurs when a human operator uses the 
personal terminal 44 to pay for the purchase of goods or 
services from a vendor terminal 46. This can occur when the 
human operator interacts with the personal terminal's human 
interface to specify the amount of value to be negotiated to 
the vendor terminal 46. The vendor terminal 46 has means 
to determine that the value negotiated by the personal 
terminal 44 is consistent with the value of the goods or 
services being purchased- For example, the human operator 
of the personal terminal 44 can scan goods across a bar code 
reader in communication with the vendor terminal 46 
thereby communicating the value of the goods to the vendor 
terminal 46. The vendor terminal can also accomplish this 
by having a human operator communicate appropriate 
instructions through the vendor terminal's user-interface in 
the same manner that a human operator communicates 
instructions to a personal terminal 44. In either case, the 
vendor terminal 46 execates software instructions required 
to accept delivery of the uninspected packet from the 
personal terminal 44. 

The vendor terminal can then deposit the data packet, now 
in uninspected form as a result of negotiation, by transmit- 
ting it to a depository account custodian 48, which can be 
either a different account custodian 48, as illustrated, or the 
same account, custodian 42. This requires that the vendor 
terminal execute software instructions to establish commu- 
nication with the account custodian, to specify the data 
packets to be deposited, and to specify an account into which 
value corresponding to those data packets should be cred- 
ited. This step can be initiated manually, by having a human 
operator communicate the appropriate instructions through 
the vendor terminal's user- interface, or automatically at 
predetermined intervals. 

The depository account custodian 48 then transmits the 
data packet to the central bank 40 for inspection, in a manner 
set forth below. If the data packet passes inspection, the 
central bank 40 withdraws it from circulation by deleting its 
corresponding entry in the validation database and issues a 
credit to the account specified by the vendor terminal 46. 

FIG. 4 shows another possible life cycle of a data packet. 
As was the case in FIG. 3, the data packet enters circulation 
upon withdrawal from the account custodian 42 by the 
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personal terminal 44. The personal terminal 42 then nego- 
tiates the data packet to a second personal terminal 45, 
thereby placing the data packet in an uninspected state. 
Before the second personal terminal 45 can negotiate the 
data packet to a third personal terminal 47, it must have the 
data packet inspected. It does so by presenting the data 
packet to a home based terminal 49 which is in communi- 
cation with the central bank 40 through an account custodian 
50. The data packet is transferred to the central bank, 
inspected, and transmitted back to the second personal 
terminal 45 in inspected form. The second personal terminal 
can then negotiate the inspected data packet to a third 
personal terminal 47. This third personal terminal deposits 
the data packet for credit to an account by presenting it to 
another home-based terminal 51 which is in communication 
with the central bank 40 through a depository account 
custodian 48 as described in connection with FIG. 3. 

FIGS. 3 and 4 illustrate just two of the many possible 
life -cycles of a value carrying data packet in the system of 
the invention. Each life-cycle includes the fundamental steps 
of minting, withdrawing, negotiating, inspecting and depos- 
iting. These fundamental steps and their interactions will be 
discussed in more detail below. 

Upon receiving a minting request 401 from an account 
custodian 42, a central bank 40 executes software instruc- 
tions which verify that the account custodian 42 is suffi- 
ciently creditworthy to receive a data packet having the 
requested denomination. If the central bank deems the 
account custodian creditworthy, it initiates the minting pro- 
cess by executing additional software instructions which 
assemble a data packet 100 having an encrypted cash serial 
number 10 and a validation check number 20 as shown in 
FIG. 1. 

Referring to FIG, 1, the validation check number 20 
incorporates the information transmitted by the account 
custodian 42 as part of the minting request 401. The software 
instructions executed by the central bank 40 for assembling 
a data packet initially set the remaining value field 22 to the 
same value as that stored in the denomination field 12 and 
set the circulation field 36, in this case the most significant 
bit in the remaining value field 22, to indicate that the data 
packet is in the non-circulating state. 

After assembly, the central bank 40 transmits the data 
packet 100 to the account custodian 42 and updates a 
validation database 43 to indicate the existence and current 
state of the newly minted data packet 100. The data packet 
100 continues to reside, in an inspected and non-circulating 
state, with the account custodian 42 until the account cus- 
todian receives a withdrawal request 403 from a personal 
terminal 44 specifying a denomination to be withdrawn and 
an account from which to withdraw it. 

When the account custodian 42 receives a withdrawal 
request 403 from a personal terminal 44, the account cus- 
todian first determines whether the personal terminal is 
authorized to withdraw a data packet having the requested 
denomination. This requires that the account custodian 
determine that the account from which value is to be debited 
has sufficient value to debit. If the account custodian deter- 
mines that the personal terminal 44 is authorized to with- 
draw a data packet having the specified denomination, it 
chooses a data packet 100 having the requested denomina- 
tion and changes its circulation status field 36 to indicate that 
the data packet is in a circulating state. The account custo- 
dian 42 then communicates the identity of the data packet 
placed into circulation to the central bank 40, thereby 
triggering the execution of software instructions by the 
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central bank which update the validation database 43. 
Finally, account custodian transmits the data packet 100 to 
the personal terminal 44. 

FIG. 5 depicts two withdrawal mechanisms in the illus- 
trated embodiment. Withdrawal can occur when an account 
custodian 62 transfers a data packet directly to a personal 
terminal 64. Alternatively, withdrawal can occur when a 
home-based terminal 66 in communication with an account 
custodian and having a user-interface similar to that of an 
automated teller machine acts as an intermediary between 
the account custodian 62 and a personal terminal 68. 

The data packet 100, now in its circulating and inspected 
state, resides in the personal terminal 44 until it is "negoti- 
ated" to another terminal. Negotiation is the transfer of a 
data packet from a transferor terminal, typically a personal 
terminal 44, to a transferee terminal, typically a vendor 
terminal 46 as shown in FIG. 3 or another personal terminal 
45 as shown in FIG. 4. A salient feature of the negotiation 
method of the invention is that it involves only a transferor 
terminal and a transferee terminal with no intervention by a 
centralized database. Another salient feature of the negotia- 
tion method is that the data packet is transformed from an 
inspected state 100, in which it is freely negotiable, to an 
uninspected state 110, in which it is non-negotiable. 

The negotiation method begins when the transferor 44 
uses a cryptographic algorithm 37 and the transfer authori- 
zation key 24 of the inspected data packet 100 to generate a 
hash code as shown in FIG. 6 A. The transferor then replaces 
the entire validation check number 20 of the inspected data 
packet 100 with a transfer authorization number 30 as shown 
in FIG. 6B. The hash code 39' generated by the transferor 44 
is stored in the transfer hash field 39 of the transfer autho- 
rization number 30. A value to be negotiated 38* is then 
stored in the negotiated value field 38 of the transfer 
authorization number 30. 

Referring to FIG. 2, the transfer authorization number 30 
further includes: the personal terminal sequence number 32; 
a personal terminal time stamp 34 indicating the date and 
time of negotiation; and an inspection check number 26 
which is an arbitrary number assigned by the central bank 
upon minting the data packet. 

In many cases, the value to be negotiated 38' is less than 
the value found in the remaining value field 22. When this 
occurs, the transferor terminal replaces the original data 
packet with a data packet to be negotiated and a data packet 
to be retained, each having the same encrypted cash serial 
number 10, The transferor terminal then decrements the 
remaining value field 22 of the data packet to be retained by 
the value to be negotiated 38' and sets the negotiated value 
field 38 of the data packet to be negotaiated to the value to 
be negotiated 38'. The data packet to be negotiated is then 
treated as set forth above. 

The negotiated data packet, now in its uninspected state, 
is then transferred to the transferee terminal 46 as shown in 
FIG. 6C. The transferee terminal 46 shown in FIG. 6C can 
be a vendor terminal 46, as shown in FIG. 3, or another 
personal terminal 45 as shown in FIG. 4. In either case, the 
transferee terminal 46 now has two choices: it can deposit 
the data packet into an account at a financial institution, as 
illustrated by FIG. 3, or it can further negotiate the data 
packet, as illustrated by FIG. 4. 

Referring to FIG. 4, if a transferee terminal, in this case 
a second personal terminal 45, chooses to further negotiate 
the data packet, it must first have the data packet 
"inspected." Inspection is the process of verifying: that an 
entry corresponding to the data packet to be inspected exists 
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in the validation database 43; that the transfer hash gener- 
ated by the transferor terminal 44 and stored in the transfer 
hash field 39 is consistent with both the transfer authoriza- 
tion key 24 found in the validation database 43 and with the 
value 38' placed by the transferor terminal in the negotiated 5 
value field 38; and that the value transferred is not in excess 
of the value stored in the data packet's denomination field 
12. 

FIG. 7 A shows a typical configuration of terminals for 
inspecting a data packet. A personal terminal 44 is connected 10 
to an inspection terminal 81. An inspection terminal can be 
an account custodian, a home based terminal linked to an 
account custodian, or a vendor terminal linked to an account 
custodian. The inspection terminal 81 typically is linked to 
a central bank 40 by a secure communication channel. 

Referring to FIG. 7 A, the transferee terminal 44 initiates 
the inspection process by presenting the uninspected data 
packet 110 to an inspecting terminal 81. The inspecting 
terminal then presents the data packet 110 to the central bank 
40 by way of an account custodian 42. The central bank 40 2Q 
locates an entry 111 corresponding to the data packet in the 
validation database 43. This entry 111 will be a copy of the 
data packet as it appeared when it was last in an inspected 
state. As such, it will have the same cash serial number 10 
as the uninspected data packet 110. However, since the entry ^ 
111 is a copy of the data packet in its inspected state, it will 
have a validation check number 20 in place of the unin- 
spected data packet's transfer authorization number 30. 

If the central bank 40 does not find a corresponding entry 
111 in the validation data base 43, it rejects the data packet 3Q 
110 by sending it back to the transferee terminal 44 in an 
uninspected state. 

If the central bank does find a corresponding entry 111, it 
verifies that the negotiated value 38 in the data packet's 
transfer authorization number 30 is less than or equal to the 35 
original denomination 12 of the data packet. 

Upon passing the above two tests, the central bank then 
verifies that the contents of the transfer hash field 39 
contained in the uninspected data packet's transfer authori- 
zation number 30 correspond both to the transfer authori- 40 
zation key 24 stored in the corresponding entry 111 in the 
validation database 43 and to the negotiated value stored in 
the negotiated value field 38 of the uninspected data packet. 
It does so by evaluating the inverse of the cryptographic 
algorithm 37 used by the transferor terminal and verifying 45 
that the hash code in the transfer hash field 39 generates the 
correct transfer authorization key 24 and a negotiated value 
consistent with that found in the negotiated value field 38 of 
the uninspected data packet. 

Failure of any one of the foregoing tests by the data packet 50 
110 results in rejection of the data packet by the central bank 
40. The rejected data packet 110 is then returned to the 
transferee terminal 44 in an uninspected state. 

If the central bank 40 is satisfied with the authenticity of 
the data packet 110 being inspected, it transforms it into an 55 
inspected state 100. To do so, the central bank 40 replaces 
the data packet's transfer authorization number 30 with a 
new validation check number 20' as shown in FIG. 7B. This 
validation check number is typically different from the 
validation check number 20 attached to the data packet when 60 
it was last in an inspected state. The central bank then 
updates the validation database by replacing the data pack- 
et's previous validation check number 20 with this new 
validation check number 20'. Finally, the central bank 40 
transmits the data packet 100, now restored to an inspected 65 
state, back to the transferee terminal 44 by way of the 
inspecting terminal. 



As an alternative to further negotiating the data packet, 
the transferee terminal can surrender the data packet in 
exchange for credit in an account at a financial institution 
equal to the value specified by the negotiated value field 39 
in the transfer authorization number 30 of the data packet. 
This transaction, shown in FIGS. 8 A and 8B, begins when 
the transferee terminal presents the data packet 110, together 
with instructions 82 on what account to credit, to an account 
custodian 42. The account custodian 42 surrenders the data 
packet to the central bank 40 with instructions to withdraw 
the data packet from circulation and to credit the account 
custodian 42 with value corresponding to that encoded in the 
data packet 110. The central bank 40 then inspects the data 
packet 110 as set forth above. If the data packet 110 passes 
inspection, the central bank 40: credits the account custodian 
42 with the value encoded in the data packet; removes the 
data packet's corresponding entry 111 from the validation 
database 43; and transmits a message 84 to the account 
custodian 42 to indicate that its account has been credited. 
The account custodian then credits the account specified by 
the instructions 82 from the transferee terminal 44. 

Having described the invention, what is claimed as new 
and secured by Letters Patent is: 

1. A data packet created by an issuing module at the 
request of a requesting module, said data packet being 
representative of a cash note and comprising 

encrypted identifying means for uniquely identifying said 
data packet, said encrypted identifying means including 
a representation of an original face value; 

cleartext identifying means including a representation of 
a current face value less than or equal to said original 
face value and specifying an inspection state of said 
data packet, said inspection state being switchable 
between an inspected state having a transfer authori- 
zation key and an uninspected state having a hash code 
derived from said transfer authorization key. 

2. A data packet representative of a cash note and adapted 
for secure transfer from a transferor terminal having a 
signature to a transferee terminal, said data packet compris- 
ing 

encrypted identifying means permanently identifying said 
data packet; 

cleartext identifying means specifying an inspection state 
switchable between an uninspected state in which said 
transfer from said transferor terminal to said transferee 
terminal is restricted and an inspected state in which 
said transfer from said transferor terminal to said 
transferee terminal is unrestricted. 

3. The data packet of claim 2 wherein said cleartext 
identifying means includes a field in which said transferor 
terminal can affix said signature. 

4. The data packet of claim 3 wherein said signature 
comprises a hash code derived from said cleartext identify- 
ing means in its inspected state. 

5. A method for inspecting a data packet in possession of 
a holder upon transmission of a request from said holder to 
an inspector having an associated inspection database con- 
taining records of valid data packets, said data packet 
representative of a cash note and having 

a first encrypted identification means permanently iden- 
tifying said data packet, said encrypted identification 
means including a representation of an original face 
value; 

a first cleartext identification means specifying an inspec- 
tion state switchable between an inspected state and an 
uninspected state, said cleartext identification means 
indicating that said data packet is in an uninspected 
state; 
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a corresponding data packet in said inspection database, 
said corresponding data packet having a second 
encrypted identification means identical to said first 
encrypted identification means and having a second 
cleartext identification means indicating that said cor- 
responding data packet is in an inspected state, said 
second cleartext identification means having means to 
independently generate said first cleartext identification 
means; 

said method comprising the steps of: 

transferring said data packet from said holder to said 
inspector, 

verifying that said data packet has a corresponding data 

packet in said inspection database, 
verifying that said data packet is in an uninspected state, 
verifying that said current face value of said data packet 

is less than or equal to said original face value of said 

data packet, 

independently generating said first cleartext record from 
said second cleartext record, 

verifying that said first cleartext record and said indepen- 
dently generated first cleartext record are identical, 

altering said first cleartext record to indicate that said data 
packet is in an inspected state, and 

replacing said second cleartext record with said altered 
first cleartext record, 

transmitting said data packet from said inspector to said 
holder, 

such that said data packet in possession of said holder 
includes a cleartext record identifying said data packet as an 
inspected data packet. 

6. The method of claim 5 wherein said step of indepen- 
dently generating said first cleartext record from said second 
cleartext record comprises the steps of: 

reading an identifying field from said first cleartext 
record, 

reading a transfer authorization key from said second 

cleartext record, and 
applying a hash coding function to said identifying field 

and said transfer authorization key to generate a hash 

code, said hash code being identical to a corresponding 

hash code on said first cleartext record. 

7. The method of claim 6 wherein said step of altering said 
first cleartext record to indicate that said data packet is in an 
inspected state comprises the steps of: 

deleting said corresponding hash code from said first 

cleartext record, 
deleting said identifying field from said first cleartext 

record, 

generating a transfer authorization key, and 
adding said transfer authorization key to said first cleart- 
ext record. 

8. A method for negotiating a data packet in the posses- 
sion of a transferor module having data processing means to 
a transferee module, said data packet representative of a cash 
note having 

an inspection state switchable between an uninspected 
state and an inspected state and set to the inspected 
state; 

an encrypted record uniquely identifying said data packet; 
and 

a cleartext record specifying said inspection state of said 
data packet, said cleartext record including a transfer 
authorization key; 
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method comprising the steps of: 
reading said transfer authorization key, with said data 

processing means, from said cleartext record, 
writing with said data processing means, an identifying 
5 field to said cleartext record, 

generating with said data processing means, a signature 
based on said transfer authorization key and said iden- 
tifying field, 

io writing, with said data processing means, said signature to 
said cleartext record, thereby indicating that said data 
packet is in an uninspected state, 
transmitting said data packet to said transferor module such 
that said inspected data packet in possession of said trans- 
15 feror module becomes an uninspected data packet in pos- 
session of said transferor module. 

9. A system for the secure transfer of a data packet 
representative of a cash note having 

an encrypted record uniquely identifying said data packet, 

20 a cleartext record specifying an inspection state switch- 
able between an inspected state and an uninspected 
state, and a circulation state switchable between a 
circulating state and a non-circulating state, 
said system comprising: 

25 a central bank terminal for issuing said data packet, said 
central bank terminal maintaining a record for said data 
packet and having means to authenticate said data 
packet and means to alter said inspection state of said 
data packet from being in an uninspected state to being 

30 in an inspected state; 

an account custodian terminal for receiving said data 
packet issued by said first database system, said 
account custodian terminal having means to alter said 

35 circulation state of said data packet from being in a 
circulating state to being in a non-circulating state; 
a personal terminal for receiving said data packet from 
said account custodian system, said personal terminal 
having means to alter said inspection state of said data 

40 packet from being in an inspected state to being in an 
uninspected state 
such that said data packet issued by said central bank 
terminal is placed into circulation by said account 
custodian terminal upon being transferred by said 

45 account custodian terminal to said personal terminal. 

10. A method for negotiating a data packet from a 
transferor module to a transferee module, said data packet 
representative of a cash note and having: 

an inspection state switchable between an inspected state 
so and an uninspected state and set to an inspected state, 
an encrypted record uniquely identifying said data packet, 
and 

a cleartext record specifying said inspection state, 
said method comprising the steps of: 
55 generating a signature based on said cleartext record; 
changing said inspection state of said data packet by 

writing said signature to said cleartext record; 
transmitting said data packet to said transferee module. 
60 11. A method for circulating a data packet representative 
of a cash note, said data packet being switchable from an 
inspected state to an uninspected state, said method com- 
prising the steps of: 
transferring said data packet, in an inspected state, from a 
65 central bank to an account custodian, 

transferring said data packet from said account custodian 
to a first terminal, 
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changing said data packet at said first terminal from an 

inspected state to an uninspected state, 
transferring said uninspected data packet to a second 

terminal, 

changing said uninspected data packet at said second 

terminal into an inspected data packet, 
transferring said inspected data packet from said second 

terminal to said account custodian, 
transferring said inspected data packet from said account 

custodian to said central bank, and 
removing said data packet from circulation. 
12. A method for inspecting a data packet in possession of 
a holder, said data packet representative of a cash note and 
having 

an inspection state switchable between an inspected state 

and an uninspected state and 
a signature generated by said holder, said signature being 

based on said inspected state of said data packet, 
said method comprising the step of 
verifying that said signature is consistent with said 

inspected state of said data packet, 



15 



20 



14 



altering said data packet to indicate that said data packet 
is in an inspected state so that said data packet in 
possession of said holder is in an inspected state. 

13. A system for the secure transfer of a data packet 
representative of a cash note, said data packet having 

an encrypted record uniquely identifying said data packet, 

a cleartext record specifying an inspection state switch - 
able between an inspected state and an uninspected 
state, 

said system comprising: 

a central bank system for issuing said data packet, said 
central bank system maintaining a record for said data 
packet and having means to authenticate said data 
packet and means to alter said inspection state of said 
data packet from being in an uninspected state to being 
in an inspected state, 

a terminal for receiving said data packet from said central 
bank system, said terminal having means to alter said 
inspection state of said data packet from being in an 
inspected state to being in an uninspected state. 
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ABSTRACT 



A wireless electronic commerce system (10) comprising a 
wireless gateway (18) to a wireless network (19) with which 
a wireless device (11) having a unique client identifier (ID) 
is capable of communicating. A server (15) or servers (15 
and 16) is/are couple able to the wireless gateway, delivering 
content items (e.g. software products) to the wireless device 
(11) and maintaining digital content certificates for content 
items and digital license certificates for licenses for the 
content items. The server maintains, for each wireless client 
associated with the system, a record of licenses for that 
client and a record of content items associated with each 
license. 

7 Claims, 5 Drawing Sheets 
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SECURE WIRELESS 
ELECTRONIC-COMMERCE SYSTEM WITH 
DIGITAL PRODUCT CERTIFICATES AND 
DIGITAL LICENSE CERTIFICATES 

5 

FIELD OF THE INVENTION 

This invention relates to secure electronic commerce 
distribution and sales having the ability to offer software 
enhancements and new features in a simpler, faster, and 1Q 
cheaper method than previously available. Secure electronic 
commerce brings together three important functions: repro- 
grammable software or other content (generically referred to 
also as "product", which includes services); wireless data 
service; and security (encryption & authentication). 15 

BACKGROUND OF THE INVENTION 

Secure electronic commerce offers a way for customers to 
add or change features in their phone using the convenience 
of the wireless data service already available in the phone. 20 
Moreover, the customer can achieve these goals within 
minutes and in the comfort of the customer's home or 
business. 

Secure electronic commerce offers many advantages, ^ 
among them: greater ease of distribution, sale and revenue 
collection for software-only features; flexible and upgrade- 
able phone platform - this reduces obsolescence; ability to 
thwart theft of services and cloning; reduced warranty costs 
in case of software patch updates; and convenience of 3Q 
wireless reprogramming. 

SUMMARY OF THE INVENTION 

In one aspect, the present invention provides a wireless 
electronic commerce system comprising a wireless gateway 35 
to a wireless network with which a wireless client having a 
unique client identifier is capable of communicating and at 
least one server couple able to the wireless gateway, deliv- 
ering content items to the wireless device and maintaining 
digital content certificates for content items and digital 40 
license certificates for licenses for the content items. The 
server maintains, for each wireless client associated with the 
system, a record of licenses for that client and a record of 
content items associated with each license. 

45 

This record maintained at the server can be used for 
content item license verification as will be described and is 
particularly advantageous for repair and recovery as will be 
described. 

In another aspect of the invention, a content item is 50 
delivered to a wireless device. The content item is verified 
with the server. A license associated with the content item is 
verified and the content item is enabled at the wireless client 
when the content item and license are verified. A particularly 
useful (but not essential) feature is that rules can establish 55 
that a new license certificate is not required for every new 
content item. 
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AA Attribute Authority 

API Application Programming Interface 

CA Certification Authority 

DER Distin guinhed Encoding Rules (ASN.l) 

EC Elliptic Curve 

GSM Global System for Mobile Communication 
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Glossary of Abbreviations 



ID Identifier 

ME Mobile Equipment 

PER Packed Encoding Rules (ASN.l) 

PIN Personal Identification Number 

PK Public Key 

PKI Public Key Infrastructure 

RA Registration Authority 

RSA RSA (Rivest, Shamir, Adleman) public key algorithm 

SHA-1 Secure Hash Algorithm 1 

SIM Subscriber Identity Module 

SMS Short Message Service 

WAP Wireless Application Protocol 

WIM Wireless Identity Module 

WML Wireless Markup Language 

WML Script Wireless Markup LanguageScript 

WDP Wireless Datagram Protocol 

WTLS Wireless Transport Layer Security 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of a secure wireless electronic 
commerce system in accordance with a first aspect of the 
invention. 

FIG. 2 is a flow diagram illustrating software installation 
and boot-up steps for the wireless client device of FIG. 1. 

FIG. 3 is a flow diagram illustrating steps in a process of 
software download to a wireless device in the field or 
enabling of software in a wireless device in the field. 

FIG. 4 is a block diagram of a secure wireless electronic 
commerce system in accordance with a second aspect of the 
invention. 

FIG. 5 is a flow diagram illustrating steps of operation of 
the system of FIG. 4. 

DETAILED DESCRIPTION OF THE DRAWINGS 

The overall security model employs cryptographic API 
and underlying cryptographic toolkits providing a base level 
of security features, which other stack layers, such as a 
Wireless Transport Layer Security (WTLS) API, certificate 
standardization, and wireless applications such as a Wireless 
Application Protocol (WAP) browser, can build upon. FIG. 
1 shows the entities and relationships of the system. 

The customer interfaces with the secure electronic com- 
merce system 10 by using a wireless phone 11 or other 
wireless device plus a landline phone 12 or Internet- 
accessible computer (dialup, Ethernet, cable, etc.) 13. Vario 
within the system 10 perform the tasks of secure electro 
accessing through an Internet connection 13, or using a 
conventional telephone 12 to talk with an operator, the 
customer inputs an order to the secure electronic commerce 
system 10 at the Web server 16. 

The web server 16 communicates with the Certificate 
Authority server 15 to issue a new Product Certificate. This 
certificate will ensure that only the targeted phone 11 will be 
able to obtain and use the new feature. Because the phone 
originally contained a Product Certificate from the Software 
Server 17 (while in the factory), an audit trail, or 
accountability, is maintained for the life of the phone. The 
phone 11 cannot operate software it was not allowed to 
based on the content of the certificate. The system 10 also 
contains a copy of the phone's certificate and so it has a 
record of the capabilities of the phone. 

The Certificate Authority server 15 is a server which 
creates and distributes Public Key Certificates and License 
Certificates throughout the secure electronic commerce sys- 
tem. 
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License Certificates allow devices, such as wireless 
phones, to operate specified software products. License 
Certificates are issued to each manufactured device prior to 
leaving the factory, and subsequently when new software is 
bought. License Certificates the device's serial number as 
part of the data, which when digitally signed by the CA, will 
bind the right-to-use software license only to the phone that 
has that serial number, which by design must be unalterable. 
Therefore, these certificates can only be used by the targeted 
party and no one else. 

Public Key Certificates enable devices to establish trust 
through the CA. The CA digitally signs the certificate stating 
that a given device, denoted by its serial number, has the 
following public key associated with it. 

The Web Server 16 is the front-end server for the secure 
electronic commerce system. It may be a series of servers 
(i.e. order entry, billing, order processing, etc.) but concep- 
tually is thought of as one entity. This server contains the 
order entry system by which customers enter orders. Orders 
may be taken online through the Web, or by phone via an 
operator. This server completes the order entry by first 
verifying the user's information (user name, device serial 
number, credit card, etc.). The Web server then sends a 
request to the CA for a new License Certificate. The CA 
sends the License Certificate to the device. The License 
Certificate may be "pushed" by the CA or sent on-demand 
from the device. The device now holds the new License 
Certificate and has been authorized to use the new software. 

The Software Server 17 makes available all of the soft- 
ware products sold by the system provider/operator. It may 
be a series of servers including various factory servers but 
conceptually is thought of as one entity. The function of the 
Software Server 17 is to digitally sign software products and 
make the software product and corresponding certificate 
(known as the Product Certificate) available for download. 

The function of the WAP Proxy Server 18 is to translate 
HTML syntax into WML syntax (Internet to WAP protocol) 
and vice-versa. 

Certificates are the cornerstone of the secure electronic 
commerce system and a description of digital certificates can 
be found in Draft American National Standard X9.68-199x: 
Digital Certificates for Mobile, Account Based and High 
Transaction Volume Financial Systems, available from 
American Bankers Association Standards Department 1120 
Connecticut Avenue., NW Washington DC 20036. 

Various of the protocols and techniques in the secure 
electronic commerce system 10 operate on certificates 
(either reading/parsing certificates, or adding/modifying/ 
deleting certificates). Every device (servers 16, 17 and 18 
and wireless devices 11) in the system has one or more 
certificates. They all have a trusted root certificate which is 
the Public Key Certificate of the CA from the CA server 15. 
Given this, the secure electronic commerce system can be 
deployed. 

There now follows a description of the basic certificate 
types and the use of certificates in the lifetime of a phone. 

A Public Key Certificate contains information that ties a 
wireless device 11 with its public key. This is accomplished 
by hashing the relevant data. The certificate is comprised of 
the aforementioned data plus the hash result. Anyone wish- 
ing to verify whether the public key belongs to the device 
only needs to hash the data again, and verify that it matches 
the hash result stored with the certificate. 

Additionally, the hash is digitally signed by a certifying 
authority. In this model the CA is the trusted certifying 
authority. That is, the previously mentioned hash result is 
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signed with the CA's private key. Anyone who has the 
public key for the CA will be able to verify the encrypted 
hash. Subsequently, if the verified hash result matches that 
of the user-computed hash of the certificate data, that tells 

5 the user that (i) the certificate must have been signed by the 
trusted CA since the CA's public key was able to properly 
verify the signed hash and (ii) the certificate does belong to 
the subject because the subject's private key can verify data 
signed by the public key. 

10 A License Certificate contains information that ties a 
wireless device 11 with certain access rights. In particular, a 
License Certificate contains, at a minimum, fields for soft- 
ware product and device serial number. The software prod- 
uct field contains a product identifier. This identifier grants 

15 the device a license to use the product. A device will be able 
to run the specified software product if its internal serial 
number, embedded in the device, matches the License 
Certificate's serial number. As in the Public Key Certificate, 
the data in the License Certificate is hashed and signed by 

20 the CA. The device will not be able to verify forged License 
Certificates since it won't be able to validate the certificate 
to the CA's signature (unless the CA has been 
compromised). 
A Product Certificate ties a content item or subject (e.g. a 

25 software product name) to a fingerprint. In this case, the 
fingerprint is the hash of the software product. Therefore, 
anyone who has a software product along with its Product 
Certificate can verify the integrity of the software by com- 
paring a user-computed hash of the software with the hash 

30 result stored in the certificate. As in the Public Key 
Certificate, the hash result in the Product Certificate is 
digitally signed by the Motorola CA. So, when the user 
compares the computed hash with the Product Certificate's 
hash result, a match implies that the software product is the 

35 same which the Motorola CA had digitally signed. 

Having described the various infrastructure devices and 
the role that certificates play in the system, the way in which 
the secure electronic commerce system is deployed can now 
be described. 

40 

The following sections describe briefly how the system 
functions using examples that occur for a device. The 
examples chosen are for a phone, and include what happens 
when the phone is setup in the factory, what happens when 

45 a user turns on and uses the phone, and what happens when 
a user wants to obtain a new feature. 

Each phone in the factory has certain some unique char- 
acteristics built-in before the unit is shipped. Physically, the 
phone must contain: (i) ROM available to run unalterable 

50 certificate verification code; (ii) EEPROM available to store 
certificates (access to the certificates storage area must be 
restricted) and (iii) an unalterable unique serial number 
(either in ROM, laser-etched, write-once memory, etc.) 
At the factory, a Public Key Certificate is generated for 

55 the phone (step 100 of FIG. 2). This can be generated by the 
Software Server 17, the CA server 15, or by the phone itself. 
The CA server 15 digitally signs the certificate and retains a 
copy of it (step 101). The phone is installed with its own 
Public Key Certificate, plus the CA's Public Key Certificate 

60 (102). (The CA, being the root certifying authority, signs its 
own certificate.) A key assumption is that inside the factory 
there is a trusted network. In this environment, the genera- 
tion of the phone's Public Key Certificate, its signing by the 
CA, and the certificate and CA's public key transference into 

65 the phone are deemed to be secure. 

Also at the factory one or more License Certificates are 
issued (step 104). The factory sends a request to the CA 
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server 15 (or the software server 17 under the root authority 
of the CA server 15) to sign a License Certificate (step 105), 
The factory provides the CA information on which software 
licenses or products the phone is supposed to have along 
with the phone's serial number. The License Certificate 
includes the following information: (i) the CA's identifica- 
tion (the issuer); (ii) the serial number of the phone (the 
subject); (iii) a list of software products the phone is licensed 
to run; and (iv) a signed (encrypted with CA's private key) 
digest (software hash) of the aforementioned components. 
The license certificate is installed in the phone at step 106. 

The license Certificate may contain multiple licenses in 
one certificate, or there may be multiple License Certificates 
with one license per certificate. Both methods are allowed. 
The CA itself will retain a copy of the phone's License 
Certificate(s). 

Now, the phone enters the software programming phase. 
The phone must contains various amounts of software - 
some base version plus some (optional) additional features, 
depending on what was ordered. The factory must install the 
correct software package(s) into the phone. The software 
packages include the software itself plus a Product Certifi- 
cate (or more generally a content item certificate). The 
Software Server 17 generates a Product Certificate (step 
110) for each software product under the same root authority 
as the CA. Both the software and Product Certificate are 
stored on the Software Server 17. The Software Server 17 is 
responsible for managing the software products and making 
them available for download. The software package and its 
certificates (i.e. digitally signed software) is installed in step 
112. 

The purpose of the certificate is to bind (i.e associate) the 
software product to a particular name (e.g. software product 
name and major version number). This association may be 
in the form of a look-up list of product names associated 
with the certificate of a product name and a predefined rule 
identifying permitted new product names (e.g. Browser 
version 1. x permits all future versions of Browser between 
version 1.0 and version 2.0). The certificate contains the 
name of the software along with a hash of the software 
product. Anyone wishing to validate the integrity of the 
software can hash the software and compare it to the one 
found in the Product Certificate. The certificate is signed by 
the Software Server, The Software Server itself has a Public 
Key Certificate signed by the CA, so a line of trust is 
maintained. 

The Product Certificate includes the following informa- 
tion: (i) the Software Server's identification (the issuer); (ii) 
the software products name (the subject); (iii) a hash of the 
software product; and (iv) a signed (encrypted with Software 
Server's private key) digest of the above components. 

The Software Server 17 retains a copy of the Product 
Certificates. It should be noted that the CA 16 may also 
perform the function of the Software Server 17, in which 
case the CA will be responsible for all three types of 
certificates. 

The phone leaves the factory installed with: (i) the CA's 
Public Key Certificate; (ii) the phone's Public Key Certifi- 
cate; (iii) one or more License Certificates; and (iv) one or 
more Product Certificates. 

A series of steps takes place every time a user turns on the 
phone. First, the phone's boot software validates all of its 
Product Certificates (step 130). That is, a hash is computed 
for each software product in the phone and compared against 
the hash stored in the certificate. Also, a line of trust to the 
CA must be established. Since the Product Certificate was 



signed by a Software Server, not the CA, the phone will 
obtain the Software Server's Public Key Certificate from the 
CA (this should only occur one time after which the phone 
will store the Software Server's Public Key Certificate in 
memory). Next, the phone's boot software validates (step 
135) all of its License Certificates. That it is, a comparison 
between the phone's unalterable serial number and the serial 
number stored in the License Certificate(s) associated with 
the products is made. If they match then the phone is allowed 
to operate the software products identified in the License 
Certificate. The software products identified in this certifi- 
cate must match the software products name field in the 
Product Certificates. In both steps, the phone's boot software 
compares the digital signature of the certificates with the 
CA's Public Key Certificate (which was installed in the 
factory) to ensure that forged certificates were not installed. 

In the event that a user wants to modify the phone, such 
as enabling an option or purchasing a new feature (see 
Examples below), a new License Certificate is obtained 
along with the software product itself plus its Product 
Certificate. The following steps take place. First, the user 
purchases the feature through the Web Server 16. Whether 
by phone or Web access, the user submits the necessary 
information to the Web Server 16, including name, address, 
credit card number, the phone's serial number, and desired 
product to purchase (step 16). The Web Server 16 verifies 
the information and creates an order ticket which is also 
given to the customer. Assuming the customers credit has 
been validated, the Web Server 16 sends the phone's serial 
number along with the name of the software product 
purchased, to the CA server 15 to obtain a new License 
Certificate. The License Certificate is made available to the 
phone to download (step 204). The user may initiate a 
sequence to obtain it. The phone validates the new License 
Certificate. If the software product was installed in the 
factory but not enabled (no license certificate), it will now be 
enabled (step 220). If the software product is not found in the 
phone, it will send a request to the Software Server to obtain 
it (step 226). 

As an optional step, the Software Server 17 may be 
configured to send software products encrypted and only to 
authenticated users, in order to prevent overloading of the 
wireless network and to prevent unauthorized users from 
obtaining the software code (despite the fact that the phone 
45 cannot run the software anyway without a valid License 
Certificate). This is done by establishing a WTLS connec- 
tion between the Software Server 17 and the phone 11 via 
the WAP proxy server 18. Each party has a Public Key 
Certificate signed by a common CA, so they trust each 
50 other's certificates. Using a key exchange algorithm, a secret 
key is derived and used for encrypting the software product 
and Product Certificate. The Software Server then sends the 
software product and Product Certificate over the air to the 
phone, the phone validates the Product Certificate and the 
purchase is complete. 

Note that in this model, if the download is interrupted or 
the software is corrupted, the user can retry the download 
any number of times. 

In the event that the phone has to be brought in to a repair 
shop, there are a number of features in the secure electronic 
commerce system available to make updates or modifica- 
tions to the phone a painless one. For example, if for some 
reason a different phone is issued to the user, the repair shop 
could transfer all of the contents of the existing phone 
(software and Product Certificates) into the new one. The 
new phone will not be able to run the software until a new 
set of License Certificates is generated for that phone's serial 
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number. Hie repair shop requests new License Certificates 
from the CA using the repair shop's Public Key Certificate 
as proof to the CA that it is empowered to do so. The CA has 
on record the License Certificates for the existing phone. 
New License Certificates are issued for the new phone, and 
the existing phone's License Certificates are put on a cer- 
tificate revocation list. If for some reason the repair shop 
needed to copy software into the new phone and was unable 
to copy it from the existing phone, the software (and Product 
Certificate) could still be downloaded from the Software 
Server as described previously. 

By implementing the secure electronic commerce system, 
new features, updated software, and software patches can be 
delivered to the phone in a timely efficient manner for the 
customer. The customer benefits from the ease of performing 
the tasks, and the almost immediate cycle time to achieve it. 
Furthermore, the security features built into the system will 
reduce incidents of theft of service or cloning. 

The following examples help clarify what potential solu- 
tions are available in a secure electronic commerce envi- 
ronment for some real world situations. 

EXAMPLE 1 

Acquiring an Application not Currently in the 
Phone 

A user is travelling overseas and wants to have access to 
a voice activated German/English translator on their phone. 
The user can purchase the German/English translator soft- 
ware product from the manufacturer or retailer. The user will 
download the application into the phone and the German/ 
English translator is operated locally on the phone, rather 
than through the service provider's infrastucture. This is 
more cost effective if the user plans to use the feature on a 
regular basis. The user feels a sense of ownership. As long 
as the user keeps the phone, he/she owns the software. The 
software operates locally in the phone. The user does not 
access the feature over the air, thereby eliminating any 
potential out-of-service conditions, bandwidth or throughput 
issues, or unexpected infrastructure downtime. The user 
pays the manufacturer or the retailer for the feature, rather 
than the service provider. 

EXAMPLE 2 

Enhanced Phone Feature 

A user wants to be able to use a new Web browser now 
available for the phone, either buyer downloading the soft- 
ware (if the phone did not contain the software when 
purchased) or by enabling access rights to the feature 
already stored within the phone. The user connects the web 
server 16 (or 1-800 number), follows instructions to pur- 
chase additional options for the phone, and waits a short 
time for the software to be downloaded, or enabled, with the 
new Web browser capability. The user gains instant satis- 
faction by accessing the feature minutes after the purchase 
is made. The cost of the feature is lower than it would 
otherwise be because the overhead to bring the feature to the 
user via electronic download is low. Because the transaction 
is authenticated by the certificate authority via the CA server 
15, theft of service is virtually eliminated. 

EXAMPLE 3 

Software Patch Update 

A software patch is issued to the field to be installed in an 
existing phones (e.g. under warranty for no charge). The user 
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is instructed how to enable the phone to begin a download 
containing the updated software. Another option is that the 
service provider can automatically update phones while the 
phone is in service, without the user aware of the upgrade. 

5 The user does not need to physically return the unit to a 
service shop. The user's phone is updated in a matter of 
minutes, rather than days spent in a service shop. An instant 
electronic record of the software download is retained in the 
system 10, rather than relying on field service reports. 

10 Certain upgrades can be done automatically without the 
user's consent, thereby eliminating any, service interrup- 
tions. The cost is minimal because no service shop is 
involved in the procedure. 

15 EXAMPLE 4 

Metered Service 

A user wants to access an audio book in his/her car during 
the commute to/from work. The user can purchase an audio 

20 book from a service provider. Access may be gained by 
means of a secure data service connection which allows the 
metered service (either per book or per minute). Among 
other options, two-way communications allow the user to 
suspend/resume the transmission. This is a new type of 

25 service not achievable without secure electronic commerce. 
Thus a wireless electronic commerce system has been 
described having a wireless gateway 18 to a wireless net- 
work 19 with which a wireless client device 11 having a 

30 unique client identifier is capable of communicating. At least 
one server has been described coupleable to the wireless 
gateway, delivering content items to the wireless device and 
maintaining digital content certificates for content items and 
digital license certificates for licenses for the content items. 

35 In the preferred embodiment the server 17 delivers the 
content and the CA server 15 maintains the digital license 
certificates. The at least one server maintains, for each 
wireless client associated with the system, a record of 
licenses for that client and a record of content items asso- 

4Q ciated with each license. In other words, the CA server 15 
maintains a database or list correlating wireless client IDs 
with licenses (or license certificates) for each client ID and 
content items (e.g. software products) associated with the 
licenses. 

45 It has been described that the wireless client is able to 
request digital license certificate verification for a new 
content item when the new content item is associated with 
an existing digital license certificate that is associated with 
the client identifier, Content of a first wireless client with a 

5Q first identifier is preferably able to be replicated in a second 
wireless client with a second identifier by reloading the 
content to the second wireless client; replacing, in the at 
least one server, a first association between the first identifier 
and corresponding records of- first client licenses and first 

55 client content items, with a new association between the 
second identifier and the corresponding records of first client 
licenses and first client content items; and verifying, for the 
second client, the first client licenses and first client content 
items, whereby the second client is able to assume the 

60 functionality of the first client. 

Also described is a method of operating a wireless elec- 
tronic commerce system comprising: maintaining at at least 
one server, digital content certificates for content items and 
digital license certificates for licenses associated with the 

65 content items; maintaining at the at least one server, for each 
wireless client associated with the system, a record of 
licenses for that client and a record of content items asso- 
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dated with each license; establishing communication To describe further aspects of the electronic commerce 

between the at least one server and a wireless client device system, the following are now described: the security 

via a wireless gateway; delivering a content item to the domains; the attributes to be distributed/protected in the 

wireless device having a unique identifier within the system; system; attribute ownership assigned to domains (note some 

verifying the content item with the at least one server; 5 attributes are owned by more than one domain); and the 

verifying a license associated with the content item; and architecture for the enrollment and authentication of domain 

enabling the content item at the wireless client when the mem bers and assignment of attribute, 

content item and license are verified. . „, . „ u . , . „ . , , . e 

THe license for the content item is preferably verified , , domam • ° r * f mam , ' 15 f P u " ,c infra " 

when a name for the content item is pre-associated with a ln structure under the control of a sragle authority and using a 

digital license certificate associated with the unique identi- 10 <> cfinc ? internal naming scheme algorithms, and polices, 

fier for the wireless device. Alternatively the name for the Domain ™**> n *l flows u l ° r a dotnalD root certification 

content item satisfies a predefined rule of a digital license havm e a 6 loba "y n f me - This aUows 

certificate associated with the unique identifier for the wire- domains to generate agreements and hook together forming 

less device, for example it falls within a range of permitted „ a 8*° bal P ??-. ^ ^ * at ^» been f at ° ned m 8 domau 

version numbers identifying it as an upgrade of a content 15 by the certifymg of the public key that fee entUy owns wjtbw 

item pre-associated with the digital license certificate. lhe doma ! n * a domain membe ^ J^- { f 0 ^ ar ° °* 

rr% t „ j •< j /v possible WAP domains, some or all of which will be referred 

The secure electronic commerce system described otters ; r . / \ \ i . / \ ■ i 

, , .. - i • i ..i to: manufacturer(s); network; operator(s); wireless service 

a solution to enabling software sales over wireless networks. , x V .# * a / u i- 

™ t . . re • j r - ji .t j provider(s); content/services providers (e.g., banking 

The system is a robust, efficient, and user-friendly method to 9n *, . . \ , ... , . . r . , -\ A 4 

.* r . 20 domain); trusted thud party domains (e.g., an independent 

provide e-commerce services for customers. *• * .u •* \ j ■ /a ♦ 

K m t , .,,..„,., . certification agent or authority); device owner (fleet operator 

The system has been desenbed with a Wireless Apphca- domain); md device user ^owl domain), 

tion Protocol (WAP) server or gateway 18, but it will be A u ' „ . , . ' , . . 

understood that any wireless network gateway can be used, a " nbu ' e 15 ei,h « a characteristic (which can be 

WAP being merely a convenient protocol. Alternative 25 considered to be a name) or a nght (i.e. a permission, for 

aspects of the system are now described, also in the context ° xam P e 8 P e ™^'°" <° ««» » purchased serv.ee). 

of a WAP protocol and it will be understood that other Examples of attributes, are owned objects (e.g. directories & 

protocols can be used. flles > hardware and & interfaces) and owned rights/ 

fr .1 , . ., r ,,, A n jii;»hi c .i_ permissions (e.g. make call: establish network connection; 

Further details of the WAP server and WAP layers of the ' $MS ^ * read/writeMpdate files & directories; 

secure wireless electronic commerce system are now 30 c a • u a . 1 

, , A r ,,, A T^ , • ' ^ configure device hardware; access network management 

desenbed. A set of WAP protocols in transport, security, station 
transaction, session and application layers are described in 

the document "Wireless Application Protocol Architecture In ordcr t0 implement this security infrastructure, the 

Specification" [WAPARCH], WAP Forum, 30Apr.l998. WAP ^ bhc Ke M svstera 10 enrolls and authenticates WAP 

WAP security functionality includes the Wireless Transport 35 domain members and distribute attributes. Note that the 

Layer Security [WAPWTLS]WAP Forum, 30Apr.l998 and word "distribute" includes "distribute to purchaser"; i.e., 

application level security, accessible using the Wireless subscribers may be purchasing attnbutes such as access to 

Markup Language Script [WMLScript]. The security pro- content or services. 

vided in WAP can be of various levels. In the simplest case The WAP PKI architecture consists of autonomous secu- 
anonymous key exchange is used for creation of an 40 rity domains tied together by cross-certification. Such cross- 
encrypted channel between server and client; in the next certification is a part of service roaming agreements between 
level a server provides a certificate mapping back to an service providers and system operators. Cross certification is 
entity trusted by the client; and finally the client itself may the process by which two domain root CA's issue one 
possess a private key and public key certificate enabling it to another cross-certificates; thereby authorizing one another's 
identify itself to other entities in the network. The infra- 4s root certificates (keys), Cross-certificates generally contain 
structure and procedures required to enable the trust re la- the address of one or more inter-domain validation servers 
tionships needed for authentication of servers and clients are and may also contain other information related to the 
described in greater detail here. The term "server" used here cross-certification agreements. For the wireless industry 
is not limited to a dedicated WAP gateway but may include cross-certification can be similar to creation of roaming 
third parties and content/service providers using the WAP 50 agreements. Within a security domain the algorithms, nam- 
protocols. The specifications for the aforementioned and ing scheme, and policies of that domain are determined by 
other WAP protocol layers are found at URL: http:// the owner of the domain. During the cross-certification 
www.wapforum.org/. procedure, domains agree on interoperability issues and 
In addition to the above-mentioned documents, reference configure validation servers to allow certificate validation to 
can be made to: "Wireless Control Message Protocol 55 De performed. 

Specification", [WAPWCMP] WAP Forum, Apr. 30,1998; Classes of WAP operation are: class 0: anonymous 

WAP Identity Module Specification [WIM], WAP Forum, authentication only; class 1: server authentication only; and 

Mar. 12 1999; Digital Certificates for Mobile, Account class 2: server and client authentication. Class 0 is not of 

Based, and High Transaction Volume Financial Systems concern here as it does not involve a PKI. Class 1 involves 

[X968], Mar. 1,1999 ANSI draft; "Standard Specifications 60 the authentication of servers to clients. These servers may be 

For Public Key Cryptography", IEEE P1363/Dla (Draft owned by the wireless service provider or may be third party 

Version la) [P1363], Feb. 1998. URL: http:// servers offering their services in the network. By including 

grouper.ieee.org/groups/1363/; PKCS #1: RSA Encryption these third party servers in the WAP PKI the wireless service 

Standard", version 1.5 [PKCS1], RSA Laboratories, Nov. provider indicates a special status or stamp of approval to 

1993; PKCS #15: and Cryptographic Token Information 65 these services. Class 2 operation allows a client (mobile 

Standard" [PKCS 15], working draft version 1.0, RSA subscriber) to enroll as a member in the domain and obtain 

Laboratories, Nov. 1998. benefits of being in such a domain. This may involve special 
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agreements with third parties such as discounts or special in a wireless system holding subscriber identity and authen- 

services. Domain members may be issued small attribute tication information. The SIM card can also be used to run 

certificates, tied to their domain private key, that indicate applications needing a secure environment. The client 

purchased services or special rights being granted. device preferably also has a WAP Identity Module (WIM) 

Attribute certificates are of two types: (i) purchased 5 that provides an interface for service relating to the use of 

service or product certificates, which are like monthly sub- the WAP security layer as well as data storage services. The 

scriptions and do not require special revocation procedures; WIM uses PKCS 15 for object formats. The WIM may be an 

and (ii) system operations permissions, which are attributes interface layer to the SIM card 452, or it may be a SIM or 

issued to allow users special system configuration rights. other card with a native WIM interface on it, or a software 

These latter may be used by wireless service provider 10 token on the wireless device 450. 

personnel or issued to authorized subscribers. M{ items of nG 4 bclong t0 a domain 500> which ^ mis 
Above, several domains have been identified. The usage embodiment is a wireless network operator domain. The 
of some of these domains is now described. domain 500 may have a higher registration authority, that is 
The device owner domain is a domain used to set up an entity authorized to make requests to issue/revoke/update 
device users and user profiles/privileges without wireless 15 certificates to a CA or AA. The registration authority can be 
service provider involvement. This could be done by having considered similar to an account manager in function and is 
the service provider give the device owner a service provider responsible for member enrollment and/or attribute assign- 
domain identity and attributes to modify their account ments. Enrollment is the process by which a user public key 
configuration. Or the device owner could be made an is certified in a domain by the issuance of a domain 
attribute authority in the service provider domain. The 20 certificate containing this key. 

device owner does not necessarily need his own domain, Server 400 is a validation server. A validation servers is a 
although in a large fleet where device owner needs to issue server that ^ configured to validate certificates for domain 
certificates to employees allowing them certain rights it is members. Domains that cross-certify are expected to pro- 
preferable to have such a domain. The system allows for vide acceS sible validation servers that obtain and validate 
device owner domains, although they are not expected to be 25 certificate chains. This service is important when there are 
deployed initially as simpler means (using service provider domains with local naming schemes. Since these schemes 
domain) exist for the required functionality. may nol be understood by an outside domain, it is necessary 

Manufacturer domain is used for device bootstrap, device for the validation service to be provided. A validation server 

OS code upgrades & features. that is configured to communicate with one or more outside 

Wireless service provider domain and/or network opera- 30 domains is an inter-domain validation server. In addition 

tor domain can be used for WAP gateway certification, validation servers may provide local domain validation for 

content provider certification, subscriber feature thin clients that are domain members but do not have the 

distribution, subscriber identification (bind to account), ability to obtain and validate a certificate chain on their 

WTA scripts, over air system modifications, distribution of j t ^ possible to have multiple wireless service provider 

certificates to employees to allow system configuration. 35 domains stored in the system. If a customer switches pro- 

Content/service provider domains can be used for security viders in a system with a WIM identity card having person- 
conscious entities (e.g. banks) to run their own domains that alization and key information on it certain issues arise. If the 
cross-certify to operate with service provider domain or user simply obtains another card from the new provider all 
enroll wireless users directly. ^ the personalization information will be lost. It is therefore 

Note that a user may be a member (have a key certified) good practice, although not essential, that service provider 

in any domain. A domain is used to issue certificates to grant specific information is separated from personalization infor- 

permissions to others in a system; permissions can be mation not dependent on the service provider. It is also 

controlled on the device in a simpler manner. preferable to provide a means for the user to create a WIM 

Focus of further discussion herein is directed to the ^ software token to be used to initialize a new WIM card. 

45 

service provider, network operator, and manufacturer It is advantageous for certain businesses wishing to sell 

domains, with particular reference to FIG. 4. services or content to mobile subscribers to have their own 

FIG. 4 illustrates a CA 400 (implemented as a server). A security domain. This may be required for certain financial 

certification authority is an entity that issues/updates/ services for risk management reasons. The keys and appli- 

revokes public key bearing certificates in response to 50 cations for these domains must be separated from other 

authenticated requests from legitimate registration authori- domains in such a way that the owner is confident that no 

ties. The CA holds a private key used to sign domain tampering is possible. Although it is possible to store cer- 

member key bearing certificates. The CA is managed by a tificates and keys from any domain in the WIM, this 

wireless service provider or network operator controlling separation can be implemented in various ways that need not 

and operating a wireless network via a wireless network 55 be described. In addition to stored object separation the 

controller 401 and generating bills for customers via billing device must insure that domain applications cannot be 

computer 402. tampered with. 

A plurality of Attribute Authorities 404, 405 and 406 are Any domain member may become an attribute authority, 

shown (three are illustrated, but there may be many). An Wireless service providers distribute system management 

Attribute Authority is an entity that generates certificates 60 attributes to merchants that they bring into their domain who 

assigning attributes to domain members. Examples might be can sell their attributes- i.e. sell a purchased service ticket 

a mobile telephone manufacturer 404, a book merchant 405 (e.g. for new software as described above or for other 

and a wireless software supplier 406. content or services). 

The AAs can communicate with the end user (client) There are three types of payloads: compact pay loads, 

device 450 via a wireless gateway 420. 55 organizational payloads of which WAP payloads are one 

The client device 450 preferably (but not necessarily) has type, and domain specific payloads that are valid only in a 

a Subscriber Identity Module (SIM) 452. This is a smart card local domain. 
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In order for merchants operating AA servers 404-406 to 
define simple attributes for the service/content they sell, it is 
necessary to have a method to indicate that a given attribute 
payload is a merchant payload and to indicate the particular 
merchant. Since the payloads are not expected to be under- 5 
stood by anyone but the merchant the actual structure of the 
payload is not material. There are three ways that merchant 
attribute payloads may be identified: (i) if the merchant has 
an organizational identifier it can define its types under this 
identifier; (ii) merchant identifiers can be assigned under the 1Q 
WAP OID; (iii) domains can defines and deploy a merchant 
ID scheme for their domain specific payloads. 

Attribute certificates are preferably time-limited, i.e have 
an expiry date and be subject to periodic renewal. At any 
time when a certificate is verified, verification fails if an 15 
expiry time digitally embedded in the certificate has expired. 
A mobile client checks the validity of a merchant server 
(404-406) with the network upon first use or periodically. 
The client (either the wireless device 450 or the SIM 452 can 
be considered a client) contacts the validation server via the 20 
wireless gateway 420 for this purpose. In addition the 
wireless service provider may post a web site listing the 
status of domain merchants. Such a site could also indicate 
if the merchant is no longer a trusted domain member; i.e., 
if their certificate has been revoked for some reason. 25 

The steps by which a merchant (i.e. an AA) or other 
network element having the capacity of an AA delivers 
content to a client and receives payment for that content is 
now described with reference to FIG. 5. 

Initially, a client (450 or 452) establishes connection in 30 
step 510 with an AA server 404 via the wireless gateway 
420. The AA delivers a digital certificate to the client in step 
515. The client verifies the AA certificate in step 520. This 
is achieved at the client in the same manner as other 
certificate verification already described and is achievable 35 
because the client already has installed the public key 
certificate of the CA 400. It uses this public key certificate 
to verify the AA. The reason for this verification is because 
the client wishes to have confirmation that the AA is trusted 
by the wireless service provider. This will give the user 40 
confidence that the content to be delivered by the AA will 
operate when delivered to the wireless device 450, that it 
will not cause disruption, that the fee to be paid is as 
advertised, that upgrades will be available, etc. There are 
many reasons why the user may wish to ensure that the AA 45 
is certified by the wireless service provider. 

Next, an exchange occurs between the client and the AA 
to deliver payment to the AA for the content that the client 
is about to receive. This transaction can take one of several 
forms. The AA informs the client what the fee is for the 50 
content to be received and the client, if the user so chooses, 
authorizes payment of that fee. For example, the client can 
provide credit card details (step 535) and the AA server can 
establish a connection with a credit card server to execute a 
transaction (step 530). Alternatively, the client can deliver 55 
electronic cash to the AA server (step 535 (which need not 
be described). In a more preferred alternative arrangement, 
the client delivers a certificate to the AA that is certified 
within the wireless service provider domain 500, i.e. is 
certified by the CA 400 and has the public key certificate of 60 
the CA 400 (step 540). The AA server verifies this certificate 
in step 545 (using the root public key certificate that it 
already has stored at the AA server) and the AA is ready to 
deliver the content item (attribute) to the client. Upon 
delivery of the content item to the client (step 550) the AA 65 
instructs the CA to bill the customer for the predetermined 
fee (step 555) and the CA 400 instructs the billing computer 
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401 to add the fee to the customer's bill (step 560). Mean- 
while (step 570) the content item is enabled on the client. 

Enabling of the content item can take many forms, for 
example executing a software application or an upgrade or 
patch to a software application, or displaying a newspaper, 
or delivering a stock quote service, or opening wireless web 
access to a streaming video service or music service, or 
delivering an electronic airline ticket or a ticket to a concert, 
or many other examples. In effect, the various AAs 404, 405, 
406 all provide a virtual wireless shopping mall with a 
common billing mechanism, which is the billing mechanism 
of the wireless service provider. 

If steps 535 or 525 are executed, it is not strictly necessary 
for the AA to perform online certificate validation of the 
client's certificate (steps 540 and 545), but is preferable to 
do so anyway. As an alternative to the step of verifying the 
AA certificate (step 520) the client can just check the last 
posted AA list (or AA revocation list). In addition the 
domain provides a service that notifies merchants when a 
client certificate is revoked, so as an alternative to step 545, 
the AA can check this list. Of course, if the client is charged 
by electronic cash or credit card, steps 555 and 560 are 
omitted. 

Although several domains may be useful, it is not neces- 
sary to have users become members of these domains by 
obtaining a user key. In the case of a phone, as already 
described, the manufacturer can enroll users if direct sales to 
a user of device feature upgrades are intended. This could, 
however, also be done through distribution through the 
service provider domain or assignment to device identifiers. 
Managing user keys may be less preferable in the manufac- 
turer domain. This domain can preferably be used to authen- 
ticate features and upgrade scripts from the manufacturer. 

If the network operator runs a security domain, client keys 
may be required, but only for clients that are to be authorized 
to perform network operations from the mobile device (i.e., 
network operator employees). General client authentication 
to the network operator is not strictly necessary. 

The case of the wireless service provider assigning keys 
to users is of particular interest. The client keys are distrib- 
uted in the WIM card when service is purchased. The client 
key in the wireless service provider domain allows a mem- 
ber of this domain to assert an identity that is bound to the 
account with the provider. The service provider or its 
authorized third parties may then sell content/services in the 
domain. The client key also allows certain clients (say, 
service provider employees) to use the system to identify 
themselves to the network as having network operations 
permissions. 

For service and content providers other than the wireless 
provider that require separate security domains client keys 
are preferably issued and stored in the WIM. Domains are 
permitted to specify any naming scheme consistent with 
their network and are responsible for assuring that this 
scheme is internally consistent. A domain's internal direc- 
tory service must be configured to resolve local domain 
names. Names may be of multiple type including email 
addresses, IP addresses, DNS names, and account numbers. 
The business deploying (or contracting for deployment of) a 
domain may configure the naming mechanism to suit their 
business and system needs. 

The AAs 404, 405 and 406 can communicate between 
each other via links 408 and 409 to exchange electronic 
vouchers. For example, AA 404 can advertise to its clients 
that purchase of its services earns for the client a credit for 
the services offered by AA 405. When a client purchases a 
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content item from AA 404, AA 404 generates an automatic 
voucher that it delivers to AA 405, identifying the client by 
ID and the credit to be attributed to that client. When the 
client establishes a connection to AA 405, the client is 
informed of the discount from the fee of AA 405 that this 5 
particular client has earned. If the client purchases a service 
from AA 405, the latter can charge AA 404 for the value of 
the discount voucher or a portion thereof. There are many 
variations on this scheme that will be readily apparent to one 
of ordinary skill in the art. For example, points can be 10 
accumulated by the billing computer at the CA400 that can 
be used at any of the AAs 404-406. Alternatively, the 
voucher can be transferred to the client 450 or 452 instead 
of between the AAs so that the client can deliver the voucher 
to the next AA in the virtual wireless mall. This latter scheme 15 
is particularly simple to implement using the already 
describes public key certificate common to all the members 
of the domain 500, because any AA in the domain can 
readily verify the authentiity of the voucher. 

Further miscellaneous details of the overall secure wire- 20 
less electronic commerce system are now given for com- 
pleteness. 

Directories are organized as: domain authority name- 
>fully qualified local descriptive name->key hash, certificate 
hash, or key ID or domain authority name->key hash, 25 
certificate hash. Within a domain the domain authority name 
is implicit. A fully qualified local name is a local name that 
is unique within the domain; in some cases this is a com- 
bination of the issuer and subject names in a certificate 
(subject relative to issuer). The use of the certificate or key 30 
hash alone (no descriptive name part) for entity names is less 
preferable due to the difficulties it creates in directory lookup 
and certificate chain validation. 

An issuer below root has a name consisting of either a 35 
certificate hash and an optional descriptive name, a key hash 
and an optional descriptive name, or an integer key identifier 
and a descriptive name. Use of the integer key identifier and 
descriptive name allows for shorter and more human read- 
able names. 40 

The validator has means to obtain the necessary certificate 
path when a transaction requires that a certificate chain be 
processed. In many cases the end entity certificate itself will 
not be sent, only a name or names that allow the validator 
to obtain any required certificates. Within a domain this can 45 
be made simple by using a deterministic path naming 
scheme that allows the certificate validation path to be 
obtained directly from the (issuer, subject) pair. If the 
naming scheme does not do this internal to a certificate then 
a means external to the certificate must be provided to obtain 50 
the proper path. For validation between cross-certified 
domains it is recommended that a domain provide a secure 
validation service for its certificates. If a domain is to 
validate certificates from other domains internally then it 
must understand the naming schemes and algorithms used in 55 
the other domains. 

In certain cases a CA may have more than one valid 
certificate listed at a given time. This could happen during a 
scheduled re-key of the CA. This creates a possible problem 
when trying to follow a certificate chain as at some point the 60 
chain allows multiple possibilities. There are several meth- 
ods for dealing with this: (i) trial and error, which is 
inefficient due to the need to check multiple signatures for a 
match; (ii) use of a name type containing a key or certificate 
hash for CA's and AA's. This resolves ambiguity but makes 65 
names larger; (iii) use a key identifier with a descriptive 
name . This latter is the preferred method. 
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Given that some devices may not be capable of processing 
certificate chains for intra-domain validation, a validation 
service is defined in X9.68, This service is realized by 
providing validation servers in a domain. The addresses of 
these may be indicated as payloads in CA certificates or 
configured in some other manner. The client of the service 
must be able to verify the signature on the response so it 
must have the validation server certificate or be able to 
verify this certificate. A thin client receives a certificate that 
it wishes to validate along with an indication of the domain 
authority of the certificate; the domain is its own. The client 
sends a validation request to a validation server. The server 
sends back a signed validation response. 

For inter-domain validation, domains make certain ser- 
vices available to other domains. A cross-certificate indi- 
cates where these services may be obtained by providing an 
address for servers offering such services. The validation 
service operates between a validation client, which may be 
an intra-domain validation server, and an inter-domain vali- 
dation server. An inter-domain validation server is expected 
to be able to contact and verify the authenticity (signature) 
of a response from another domain's validation servers). 
Note that this implies that inter-domain validation servers 
must be capable of using the algorithms from the other 
domain. Inter-domain validation servers are members of 
multiple domains and therefore are able to verify signatures 
of other domains. A thin client receives a certificate that it 
wishes to validate along with the domain authority of the 
certificate; the certificate domain is not its own. The client 
sends a validation request to a domain validation server. 
Note these servers can be indicated in the root certificate as 
payloads or stored elsewhere. The validation server notes 
that the domain is external. It determines if a cross- 
certificate with the indicated domain exists. If not a valida- 
tion failure response is returned to the client. (Note that this 
third step can be skipped if the client is aware of the address 
of an inter-domain validation server). If a cross-certificate 
exists and the server is an inter-domain validation server it 
handles the request itself, otherwise it signs and sends a 
validation request to an inter-domain validation server listed 
in the cross certificate. The inter-domain validation server 
authenticates the request and either verifies the certificate 
itself or passes the request to an internal validation server in 
the other domain. The result is signed and returned to the 
validation server the client originally contacted. The vali- 
dation server authenticates the response, signs it itself, and 
returns it to the client. 

The validation service allows an entity from one domain 
to request that a certificate from another domain be authen- 
ticated. A reply of invalid is required to be returned unless 
the server can ascertain that the certificate is currently valid. 
A reason for the failure is preferably provided. 

Each domain selects the algorithms to be used internally 
for digital signatures, data enciphennent, key encipberment, 
and key agreement. In addition the maximum key size that 
can be used inside the domain is given by the domain root 
CAkey size. Domain members must have the cryptographic 
software/hardware implementing the domain algorithms 
with the maximum key size. In addition a domain member 
must have a securely loaded and stored domain root CA 
certificate or a condensed form of the domain root CA 
certificate information. 

A domain is defined so as to fix the algorithms used within 
for efficiency reasons. As a domain selects RSA with a given 
root key size the algorithm and key size are known for every 
client in that domain. This makes the impact of supporting 
another algorithm for a mobile client explicit- every new 
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domain the client joins is potentially a new algorithm. In used to generate and bind the client key insure that only one 

fact, for security reasons, some domains may not even allow binding is possible for a card and that signature keys cannot 

another domains code to be used even if the algorithm is the be determined by the service provider or their employees, 

same. The personalization process binds the public key (and hence 

A domain root CA indicates the algorithms, interna] 5 the private key) for a card to an individual account, 

naming scheme, and policies in effect in the domain. Policies For systems without identity cards, the service provider 

include such information on what guarantee the domain and network operator certificates are loaded using the manu- 

makes of member identity binding to account and what facturer root certificate to secure the loading process. The 

procedures and guarantees are made for third parties issuing manufacturer issues certificates to service providers allow- 

attribute certificates in the domain. In addition specific 10 ing them to sign key loading scripts. The device must insure 

policies for each cross-certification agreement are main- that only a properly authenticated request be used to load a 

tained. domain root certificate. 

The process of cross-certification is one in which two During a planned re-key, each CA or AA simply re-issues 

autonomous security grant formal recognition to one certificates. A device must be able to accept a certificate 

another. This is done digitally by each domain creating and 15 change order for a certificate signed by the owner of that 

signing a cross-certificate object containing the other certificate. 

domains root certificate (or its hash). In addition the Wnen a CA or AA key other than root is compromised, 

addresses of inter-domain validation servers and indications messages from root can instruct the W1M to replace the key 

of contractual agreements may be contained. witb a new key. Using root for this purpose means lower 

For service provider domains in systems with SIM or 20 level CA's need not have their own disaster recovery keys, 

WIM smart cards that are personalized at the time of service only root requires a key for this purpose, 

subscription, member enrollment comprises storing the when a root key is compromised it is desirable to have 

member certificate and key on the WIM card. procedures in place allowing recovery without re-enrollment 

For systems not having a smart card, the keys and 1$ of all domain members. For this reason each domain pref- 

certificate are stored in a WIM software token. Member keys erably has a disaster recovery public key for a domain 

are protected by passphrase information. This information is securely stored in the WIM along with the domain root 

concatenated with a stored secret value for the device and public key. The private disaster recovery key must be kept 

run through a secure hash in order to generate the in a separate system that is not connected to any network 

encryption/decryption key for use in protecting the user 3Q unless disaster recovery is underway. It is desirable that the 

private key. Member certificates are also kept with the location for this key be physically separate from the domain 

member's account and entered into the service provider root key. Disaster recovery messages are messages instruct - 

member directory. In some systems the actual member ing the WIM to automatically replace a root key. It is 

certificate may not be stored on the WIM itself but main- required that both the current root key and the disaster 

tained in the system only. For this usage the member 35 recovery key sign the root public key change message, 

certificate can be used as a secure container for account Receipt of a request for which one signature checks but the 

information and a client need only to present his identity to other is invalid must cause the WIM to be disabled. It is also 

the system; the system obtains the required certificate. For required that a message disabling the SIM AVI M card 

domains other than the service provider the enrollment entirely, signed by the disaster recovery key, be supported, 

process requires that a secure manner to store the keys in the 4Q In summary, the disaster recovery process is: message to 

WIM be defined and that each domain is assured of infor- change root signed by current root key and disaster key; (ii) 

mation message to fully disable WIM may be signed by either root 

System bootstrap involves the loading of the domain root or disaster recovery key; and (iii) receipt of a partially 

certificates and client keys. Note that in addition to a client invalid request must cause WIM to be disabled, 

signature key, keys to be used for data encipherment, key 45 A member device has keys associated with it that may be 

encipherment, and key agreement can also be loaded. Sig- used for transactions or authentication. These keys are 

nature keys for clients must be used only for signatures, generally protected by a PIN code and some "maximum 

Keys for the other purposes are also loaded. Initially the number of tries" deactivation protocol. It is desirable that 

manufacturer domain root certificate is loaded into the when a device is reported stolen, and the report itself has 

mobile device. This certificate is used to enable secure 50 been authenticated in some manner, the system be able to 

loading of other domain root certificates if necessary. In cause a card to clear keys remotely if someone attempts to 

systems not having a secure service provider provisioning use the stolen device. 

scheme in place, the manufacturers provide certificates to j^ us a met hod of conducting transactions in a wireless 

service providers giving the service provider a provisioning electronic commerce system has been described, where the 

attribute. This attribute allows a service provider to install 55 sys tem comprises a wireless network operator certification 

their root certificate in the phone. authority having a root public key certificate and at least one 

It is necessary to securely load and store domain certifi- attribute authority having a digital certificate that is depen- 

cates. Initially the device manufacturer certificate is loaded dent from the root public key certificate, where the attribute 

into the device as indicated above. Next service provider and authority is accessible by a wireless client device via a 

network operator certificates are loaded. Once valid service so wireless network. According to the method described, a 

provider and network operator certificates are loaded these wireless communication is established between the wireless 

domains gain control of attributes their domains own. Manu- client device (450 or 452) and the attribute authority (404, 

facturer domain loses control of any attributes it does not 405 or 405). The digital certificate is delivered from the 

own in a provisioned device. attribute authority to the wireless device, the attribute 

For systems with SIM cards, the wireless service provider 65 authority is verified to the wireless client device using the 

root certificate and client key and certificate are distributed digital certificate and the root public key certificate pre- 

on the card before it is issued to the subscriber. The means loaded in the wireless client device under authority of the 
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wireless network operator. An attribute is delivered to the 
wireless client device over the wireless network and ulti- 
mately enabled at the wireless client device. 

Payment for the attribute may be transacted by delivering 
a second digital certificate from the wireless client device to 5 
the attribute authority and verifying the second digital 
certificate using the root public key certificate from the 
certification authority. An instruction is preferably trans- 
ferred from the attribute authority to a billing computer of 
the wireless network operator to add an item to a wireless 1Q 
network operator bill for the wireless client device. 

The second digital certificate may be pre-loaded into the 
subscriber identity module by the wireless network operator 
or pre-loaded into a wireless communicator under authority 
of the wireless network operator. 

Also described is a method of conducting transactions in 
a wireless electronic commerce system comprising a wire- 
less network operator certification authority having a root 
public key certificate and at least first and second attribute 
authorities, having respective first and second digital cer- 
tificates that are dependent from the root public key 20 
certificate, where the attribute authorities are accessible by 
a wireless client device via a wireless network. The method 
includes establishing a wireless communication between the 
wireless client device and the first attribute authority; deliv- 
ering a first attribute to the wireless client device over the 25 
wireless network; generating an electronic voucher verifi- 
able by the second attribute authority; establishing a wireless 
communication between the wireless client device and the 
second attribute authority; requesting a second attribute 
from the second attribute authority; identifying the elec- 30 
tronic voucher at the second attribute authority; and deliv- 
ering the second attribute from the second attribute authority 
to the wireless device. The step of generating an electronic 
voucher verifiable by the second attribute authority may 
include delivering the electronic voucher from the first 35 
attribute authority to the second attribute authority via a 
connection therebetween or may include delivering the 
electronic voucher from the first attribute authority to the 
second attribute authority via the wireless client. 

Also described is a wireless electronic commerce system 49 
comprising: a wireless network operator certification author- 
ity server having a root public key certificate; at least one 
attribute authority server coupleable to the wireless network 
operator certification authority server, having a digital cer- 
tificate that is dependent from the root public key certificate; 45 
a wireless client device having pre-loaded therein the root 
public key certificate; a wireless network coupling the 
wireless client device to the at least one attribute authority 
server; verification means in the wireless client device for 
verifying the digital certificate to the wireless client device 50 
using the root public key certificate pre-loaded in the wire- 
less client device; means (e.g. server 18 or gateway 420) 
associated with the attribute authority server for sending and 
means (e.g. a radio receiver in the wireless device 450) for 
receiving an attribute over the wireless network; and means 55 
for enabling the attribute at the wireless client device. 

The above description has been given by way of example 
only. Other aspects, objects and advantages of the invention 
and modifications of detail will be apparent to one of 
ordinary skill in the art reading the teaching herein. All such eo 
modifications are included within the scope and spirit of the 
claims. 

What is claimed is: 

1. A wireless electronic commerce system comprising: 

a wireless gateway to a wireless network with which a 65 

wireless client device having a unique client identifier 

is capable of communicating; and 
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at least one server coupleable to the wireless gateway, 
delivering content items to the wireless client device 
and maintaining digital content certificates for content 
items, the digital content certificates establishing that 
the content items are available on the wireless client 
device and digital license certificates for licenses for 
the content items to enable only a specified device to 
operate a specified content item such that the digital 
license certificate can be used only by the specified 
device and no other device, 

wherein the at least one server maintains, for each wire- 
less client device associated with the system, a record 
of the licenses for the content items available 00 that 
wireless client device and a record of the content items 
associated with each of the licenses, the record of the 
licenses and the record of the content items enabling 
content item license verification on the wireless client 
device. 

2. The wireless electronic commerce system of claim 1, 
wherein a wireless client device is able to request digital 
license certificate verification for a new content item when 
the new content item is associated with an existing digital 
license certificate that is associated with the client identifier. 

3. The wireless electronic commerce system of claim 1, 
wherein content of a first wireless client device with a first 
identifier is able to be replicated in a second wireless client 
device with a second identifier by: 

a reloading the content to the second wireless client 
device; 

replacing, in the at least one server, a first association 
between the first identifier and corresponding records 
of first client licenses and first client content items, with 
a new association between the second identifier and the 
corresponding records of first client licenses and first 
client content items; and 

verifying, for the second wireless client device, the first 
client licenses and first client content items, whereby 
the second wireless client device is able to assume the 
functionality of the first wireless client device. 

4. A method of operating a wireless electronic commerce 
system, comprising: 

maintaining at least one server, digital content certificates 
for content items and digital license certificates for 
licenses associated with the content items, the digital 
content certificates establishing that the content items 
are available on the wireless client device and the 
digital license certificates to enable only a specified 
device to operate a specified content item such that the 
digital license certificate can be used only by the 
specified device and no other device; 
maintaining at the at least one server, for each wireless 
client device associated with the system, a record of 
licenses for that wireless client device and a record of 
content items associated with each license, the record 
of the licenses and the record of the content items 
enabling content item license verification on each wire- 
less client device; 
establishing communication between the at least one 
server and a wireless client device via a wireless 
gateway; 

delivering a content item to the wireless client device 

having a unique identifier within the system; 
verifying the content item with the at least one server; 
verifying a license associated with the content item; 
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enabling the content item at the wireless client device 
when the content item and license are verified. 

5. The method of claim 4, wherein the license for the 
content item is verified when a name for the content item is 
pre-associated with a digital license certificate associated 
with the unique identifier for the wireless client device. 

6. The method of claim 4, wherein the license for the 
content item is verified when a name for the content item 
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satisfies a predefined rule of a digital license certificate 
associated with the unique identifier for the wireless client 
device. 

7. The method of claim 6, wherein the predefined rule 
includes determining whether the name of content item 
identifies it as an upgrade of a content item pre-associated 
with the digital license certificate. 

***** 
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(57) ABSTRACT 

The present invention provides a method utilizing evolu- 
tionary processes for solving partial constraint satisfaction 
problems in order to produce a near-optimal or optimal 
sequence of products for manufacture. More specifically, a 
computer implemented method for generating an optimized 
sequence of "N" number of products for manufacture is 
provided, where said products are of "M" number of distinct 
types with a fixed number ("N/') of each type being desired 
and each product type comprising an array ("Q") of distinct 
features, wherein said manufacture is optionally constrained 
by one or more of the following constraints: the production 
requirement for each product type, feature -based position 
equations, and feature-based position inequalities, wherein 
each of said constraints is individually designated as either 
a hard constraint which cannot be violated, or as a soft 
constraint which can be violated at a predetermined cost; 
said method comprising: generating an initial population of 
chromosomes, wherein each chromosome represents a fea- 
sible sequence of products of various types for manufacture, 
feasibility depending on satisfaction of all of said hard 
constraints; associating a fitness value with each 
chromosome, said fitness value being a function of the 
predetermined cost associated with the degree of violation of 
each of said soft constraints; sorting said chromosomes 
based on the fitness value associated with each chromosome; 
and applying iteratively to the population of chromosomes a 
reproductive process, comprising (1) selection of a genetic 
operator, (2) selection of one or two chromosomes, the 
number of chromosomes to be selected correlating with the 
selected genetic operator, (3) application of the selected 
genetic operator to the selected one or two chromosomes to 
cause generation of one or two offspring, (4) insertion of one 
offspring chromosome into the sorted population, and (5) 
discard of one of the least desirable chromosomes in the 
population; said iterative process being continuously run 
until the fitness value for the best chromosome satisfies a 
known criterion or until a pre-determined time has elapsed. 

26 Claims, 5 Drawing Sheets 
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METHOD FOR GENERATING NEAR- 
OPTIMAL SEQUENCING OF 
MANUFACTURING TASKS SUBJECT TO 
USER-GIVEN HARD AND SOFT 
CONSTRAINTS 

This application claims the benefit of Provisional Appli- 
cation No. 60/112,329 filed, Dec. 15, 1998. 

FIELD OF THE INVENTION 

The field of the invention is evolutionary processes; more 
particularly, the present invention relates to a method uti- 
lizing evolutionary processes for solving partial constraint 
satisfaction problems in order to produce a near-optimal or 
optimal sequence of products for manufacture. 

SUMMARY OF THE INVENTION 

The present invention relates to a method for solving 
partial constraint satisfaction problems, more particularly to 
a method of sequencing products for manufacture such that 
the sequence produced is a near-optimal or optimal 
sequence, meaning that direct cost associated with various 
labor, processes, and parts inventory are minimized and 
equipment and floor space utilization are maximized. One 
application of the method of the present invention is the 
sequencing of automobiles during manufacturing, in which 
vehicles are sequenced to go through a series of operations 
such as body forming, painting, component assembly (such 
as installing radios, seats, etc.) and final assembly (adding 
trim and chassis). 

BACKGROUND OF THE INVENTION 

The sequencing of manufacturing stages or tasks repre- 
sents a combinatorial, or partial, constraint satisfaction and 
optimization problem. 

As is understood by those skilled in the art, partial 
constraint satisfaction problems (PCSP's), such as schedul- 
ing or sequencing, do not lend themselves easily to auto- 
mated solving. A solution to a PCSP typically must satisfy 
a set of hard constraints to be valid or feasible, and must 
minimize the costs associated with violating one or more 
conflicting soft constraints (i.e., the solution must present 
the best trade-off among the conflicting soft constraints). 
The soft constraints cannot be all completely or simulta- 
neously satisfied in a solution. Thus, each soft constraint is 
allowed to be violated at a cost (i.e., partially satisfied) and 
the best solution is a valid solution (i.e., satisfying all hard 
constraints) which minimizes the costs incurred with vio- 
lating the soft constraints and the degree of violation thereof. 

PCSP's, such as the scheduling (or sequencing) of prod- 
ucts for manufacture present a particularly difficult type of 
problem — a computationally complex problem, referred to 
as an NP-complete problem (see Garey, M. and Johnson, 
D. , Computers and intractability: a guide to the theory of 
NP-completeness, Freeman, 1979.), for which search tech- 
niques that deterministically and exhaustively search the 
space of possibilities fail to generate a viable solution in a 
realistic time period. For the generic problem of assigning N 
tasks to M resources with a particular ordering of tasks at 
each resource, the number of possible solutions is 



5 

which implies super-exponential growth as a function of the 
number of tasks and resources. In addition to sheer size, this 
search space has a more complex topology than a Euclidean 
space or, when M >1, a space of permutations. 

1(J Exhaustive search (for the best sequence) is impractical 
for most of the real-world sequencing problems which often 
have a sequence length ranging from the 100' s to the 1000's 
and are subject to many conflicting constraints. Traditional 
algorithmic techniques, such as dynamic programming (see 
Bellman, R. E., and Dreyfus, S. E., Applied dynamic 

15 programming, Princeton University Press, 1962), and 
branch-and-bounds (see Lawler, E. L., and Wood, D. E., 
"Branch and bounds methods: A survey," Operations 
Research, 14, 699-719, 1966) fail due to their lack of 
scalability. The heuristic methods developed to date are 

20 complicated by the details of a particular task, and the 
algorithmic consideration of the specific constraints is 
embodied in what amounts to a domain specific expert 
system. Such heuristic techniques are often highly specific 
to particular application domains and thus are not useful as 

25 general techniques for solving PCSP problems. 

Real-world scheduling/sequencing problems present spe- 
cial difficulties not found in the less than real-world prob- 
lems addressed in the art to date. These difficulties include: 
(1) the size and complexity of the real-world search space, 

30 which is far more formidable than the search typically 
defined in less than real-world problems; (2) the dynamic 
process inherent in real -world scheduling/sequencing prob- 
lems (schedules remain valid only for a limited amount of 
time; after a certain duration, the world generally has 

35 changed enough that the scheduling algorithm has to find a 
different schedule; additionally, there are time constraints on 
how long it can take to schedule and reschedule that place 
limits on the amount of computation that can be performed 
by a scheduling algorithm; and (3) the different domains and 

40 applications present in real -world scheduling problems, 
which require solutions of different variations of the sched- 
uling problem (these variations arise from a number of 
different sources, including: differences in the types of hard 
constraints, such as relative and absolute temporal 

45 restrictions, and resource capabilities constraints; the need 
for additional information beyond an ordered assignment of 
tasks to resources, such as absolute times, routes traveled, 
and manufacturing plans; and different sets of evaluation 
criteria, such as cumulative response time, throughput, time 

50 span, and cumulative employee satisfaction.) Real- wo rid 
scheduling/sequencing algorithms thus must be flexible 
enough to accommodate different conditions and able to 
adapt to changes. 
Evolutionary computation (abbreviated as "EC"), a 

55 general, stochastic framework inspired by the intrinsically 
robust search and optimization paradigms of biological 
evolution, presents the most promising direction in solving 
real-world PCSP's. EC algorithms have been applied to 
many hard optimization problems where classical methods 

60 (e.g., gradient search, linear programming, etc.) have failed 
to provide good solutions. See, e.g.. Back, T, Fogel, D. B., 
and Michalewicz, Z, eds., Handbook of Evolutionary Com- 
putation. New York: Oxford Univ. Press and Institute of 
Physics, 1997. 

65 All EC algorithms share the same basic high-level phi- 
losophy and structure. In any EC algorithm, a "population" 
of individuals, called "chromosomes," is maintained. Each 
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chromosome represents a potential solution to the problem of chromosomes, (2) selection strategy, (3) reproduction 
to be solved. An "initialization process" is incorporated to strategy (including genetic operators), and (4) problem- 
create the initial population (i.e., the first generation of dependent criteria and method for fitness evaluation of 
chromosomes). A "fitness measure" representing certain chromosomes. For example, three pioneer classes of EC 
optimization criteria is employed to evaluate how fit or 5 algorithms, Genetic Algorithms (GAs) (see Holland, J., 
optimized each chromosome is, and a "selection process" is Adaptation in Natural and Artificial Systems, University of 
used to select chromosomes for "reproduction" based on Michigan Press, Ann Arbor, 1975), Evolutionary Program- 
their fitness values. The reproduction process applies m i ng (EP) (see Fogel, L., et al., Artificial Intelligence 
"genetic operators" to the selected chromosomes to create through Simulated Evolution, Wiley, New York, 1966), and 
probabilistically perturbed variants, called "offspring," 10 Evolutionary Strategies (ESs), differ in these components. In 
among which are likely fitter chromosomes. A unary genetic QAs, which are perhaps the most influential form of EC 
operator alters a (parent) chromosome in some fashion algorithms, a chromosome has the structure of a bit string, 
probabilistically, and is called a "mutation." A binary genetic anc j crossover is emphasized as a major operation, whereas 
operator combines probabilistically determined portions of m gp anc i £s, a chromosome represents a string of real 
two parent chromosomes to produce two offspring, and is 15 numbers, and mutation is emphasized, 
called a "crossover." The offspring chromosomes are then i n car iy applications of EC, a concrete problem descrip- 
evaluated by the fitness measure and, based on their values tion was typically mapped into a standard, well-known 
of fitness, are used to replace certain worse chromosomes in chromosome representation, such as a bit string in a classical 
the population to form a new generation. GA, and the problem was then solved by a standard, 
The general EC procedure can be outlined as follows, 2 o well-known EC algorithm, such as a classical GA. This, 
where t denotes generation index and P(t) denotes the however, has many limitations. Although bit string (or 
population of chromosomes at t: binary) representation has facilitated the development of the 
Begin theoretical foundation of GAs, bit string representation 
t=0; severely limits the range in which the algorithm can operate. 
Initialization (to create P(t) typically randomly); 25 It is thus ineffective in problems where the desired solution 
Repeat is hierarchical, or where the size and shape of the solution 
Fitness evaluation of P(t); is unknown in advance. In a classical GA, there is one 
Selection of chromosomes in P(t); mutation operator and one crossover operator. The mutation 
Reproduction to produce a P(t+1); operator flips a randomly selected bit in a chromosome to 
t=t+l; 30 produce a new offspring. The crossover operator cuts the 
Until certain termination condition is satisfied (when two chromosomes into two parts at the same (randomly 
t-T) selected) position and swaps the second parts of the two 
End. chromosomes to produce two offspring chromosomes. 
By repeating the above evaluation-selection-reproduction These operations, at the level of bits, usually make evolution 
loop, the population can be "evolved" to fitter populations 35 too slow in converging to a satisfactory solution. 
(Darwinian survival of the fittest). Note that in the process, More recent approaches emphasize the use of "natural" 
P(t) remains of the same size, i.e., has the same number of chromosome structures which best describe the class of 
chromosomes. After a certain number of generations (which problems to be solved, and accordingly, the use of problem- 
is either predetermined, or decided based on specified "ter- sensitive genetic operators (see Michalewicz, Z. Genetic 
ruination" conditions), the best chromosome in the final 40 algorithms+data structures-evolution programs, 3"* ed., 
population represents the optimal or near-optimal solution to Springer-Verlag, 1996). An important question (and 
the problem. problem) inherent in these approaches, however, is to what 
Such a EC paradigm is inherently parallel (as a whole extent should the problem-specific knowledge or informa- 
population can evolve simultaneously) and robust (as it is a tion be embedded in the algorithm to achieve a good balance 
probabilistic or randomized process). It combines exploita- 45 of efficiency and general applicability. Trying to answer this 
tion of the most promising search area, through fitness- question well is a continuing struggle for EC practitioners, 
governed selection and reproduction, and exploration of the Among the problems attacked by EC methods, scheduling 
broadest search space through randomness. problems have drawn considerable attention, see Special 
Such a EC paradigm is also general in the sense that only Issue: Evolutionary Algorithms for Scheduling, Evolution- 
the fitness function used to evaluate how "good" a chromo- 50 ary Computation, 6(1), 1998, including the specific problem 
some is requires problem-specific knowledge or informa- of car sequencing, see Warwick, T. and Tsang, E. P. K., 
tion; the other components can be relatively problem- "Tackling car sequencing problems using a generic genetic 
independent. For example, initialization is typically done by algorithm," Evolutionary computation, 3(3): 267-298, 1995. 
randomly generating chromosomes. A typical method of However, the car sequencing problems considered to date 
chromosome selection is "roulette wheel" sampling in which 55 constitute unrealistically simplified versions of the real- 
each chromosome is assigned a slice of a circular "roulette world problem, having no more than one hard constraint and 
wheel," with the size of the slice being proportional to the one type of soft constraints. The approaches considered to 
chromosome's fitness. The wheel can then be spun N times, date are also not suitable for real-world sequencing 
where N is the number of individuals in the population. On problems, which have many different kinds of hard and soft 
each spin, the individual under the wheel's marker is 60 constraints, because with multiple constraints, they do not 
selected to be in the pool of parents for the next generation. result in a feasible or valid solution within a finite time 
On the other hand, one can also design each component period. The prior art crossover operator also can result in 
of the EC paradigm (as outlined above) differently to suit severe violation of hard constraints in the offspring 
special needs of a particular problem. Thus, the EC para- produced, and repairing the infeasible offspring can be very 
digm is both general and flexible. 65 expensive. 

Indeed, different EC algorithms are characterized by In sum, there is no effective method, EC-based or not, in 

different designs of the basic components: (1) representation the prior art which is able to handle the complex real- world 
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sequencing problems successfully. The present invention 
overcomes the problems and insufficiencies in the art in a 
novel manner. 

BRIEF SUMMARY OF THE INVENTION 5 

In view of the shortcomings and inabilities of the existing 
methods for solving real- world sequencing problems, the 
present invention provides a general method of sequencing 
manufacturing tasks which employs an EC algorithm to 
determine near-optimal solutions to a partial constraint 
satisfaction problem ("PCSP"). A preferred embodiment 
comprises a method for determining within a finite time 
period near-optimal sequencing of manufacturing tasks sub- 
ject to user-given hard and soft constraints. 

It is to be understood that the foregoing general descrip- 
tion and the following detailed description are exemplary 
and explanatory only, and not restrictive of the invention as 
claimed. 



DESCRIPTION OF THE DRAWINGS 



20 



30 



The present invention will be understood more fully from 
the detailed description given below and from the accom- 
panying drawings which, however, should not be taken to 
limit the invention to the specific embodiment but are for 25 
explanation and understanding only. 

FIG. 1 depicts a chromosome (S) representation of a 
product sequence: S~{$ v S 2 , . . . , S^} be a sequence of N 
products of M types. Assume that an assembly schedule 
must be generated for a set of N vehicles. 

FIG. 2 illustrates a mutation operation. 

FIG, 3 illustrates a crossover operation. 

FIG, 4 illustrates the preferred method of the invention. 

FIG. 5 illustrates the basic operations of an automobile 35 
manufacturing sequence. 

DETAILED DESCRIPTION OF THE 
INVENTION 

40 

The present invention teaches a method of solving partial 
constraint satisfaction problems, in particular a method of 
sequencing products for manufacture such that the sequence 
produced is a near-optimal or optimal sequence, meaning 
that direct cost associated with various labor, processes and 45 
parts inventory are minimized and equipment and floor 
space utilization are maximized. An example of sequencing 
products for manufacture is the manufacture of automobiles, 
in which vehicles are sequenced to go through a series of 
operations such as body forming, painting, component 5Q 
assembly (such as installing radios, seats, etc.) and final 
assembly (adding trim and chassis). 

In the present invention, in order to be valid or feasible, 
a solution sequence must satisfy any hard constraints 
imposed. In addition, there are a number of desirable, but 55 
conflicting, constraints (referred to as "soft constraints") 
which cannot all be completely satisfied in a sequence at the 
same time. Thus, soft constraints are allowed to be violated 
at a cost, or partially satisfied. The optimal solution sequence 
will be a valid sequence (i.e., satisfying all hard constraints) go 
which also minimizes the degree and costs of violating all 
soft constraints (i.e., providing the best trade-off among the 
conflicting soft constraints). 

The present invention applies to sequencing problems 
which include some or all of the constraints described below. 65 
Constraints other than those described below may also be 
included. 



The method of the present invention comprises: A com- 
puter implemented method for generating an optimized or 
nearly-optimized sequence of W N" number of products for 
manufacture, where said products are of "M" number of 
distinct types with a fixed number ("N/') of each type being 
desired and each product type comprises a unique array 
("Q") of distinct features, wherein said manufacture is 
optionally constrained by one or more of the following 
constraints: the production requirement for each product 
type, feature-based position equations, and feature-based 
position inequalities, wherein each of said constraints is 
individually designated as either a hard constraint which 
cannot be violated, or as a soft constraint which can be 
violated at a predetermined cost; said method comprising: 
generating an initial population of chromosomes, wherein 
each chromosome represents a feasible sequence of 
products of various types for manufacture, feasibility 
depending on satisfaction of all of said hard constraints; 
associating a fitness value with each chromosome, said 
fitness value being a function of the predetermined cost 
associated with the degree of violation of each of said 
soft constraints; 
sorting said chromosomes based on the fitness value 

associated with each chromosome; and 
applying iteratively to the population of chromosomes a 
reproductive process, comprising (1) selection of a 
genetic operator, (2) selection of one or two 
chromosomes, the number of chromosomes to be 
selected correlating with the selected genetic operator, 
(3) application of the selected genetic operator to the 
selected one or two chromosomes to cause generation 
of one or two offspring, (4) insertion of one offspring 
chromosome into the sorted population, and (5) discard 
of one of the least desirable chromosomes in the 
population; 

said iterative process being continuously run until the 
fitness value for the best chromosome satisfies one or 
more known criteria or until a pre -determined time has 
elapsed. 

The problem description — described above as "N number 
of products for manufacture, where said products are of "M" 
number of distinct types with a fixed number ("N r ") of each 
type being desired and each product type comprises a unique 
array ("Q") of distinct features" can be formulated as 
follows: 

Let S«{S a , S 2 , . . . , S^} be a sequence of N products of 
M types, where each type t is described by a tuple of Q 
features (f a , f 2 , . . . , y, such that f, (i«l, 2, . . . , Q) E D fl 
where D,- is the domain of feature values for feature i. S is 
subject to hard constraints, which may or may not include 
some or all of the following types of hard constraints: 

A. Production requirements: for each product type t 
(=1, . . . , M), N(t) products have to be in the sequence S (i.e., 
have to be produced). Thus N=2N(t). (Alternatively, the 
product requirement can be included as a soft constraint.) 

B. Feature -based position equations: a set of equations 
which determine product positions based on values of a 
subset or the whole set of type features. This kind of 
constraints take into account the limitations present in the 
means of moving the sequence in the work space (e.g., the 
availability and locations of holders to carry products to 
various processes and the ways processes can be applied to 
the products). 

C Feature-based position inequalities: a set of inequali- 
ties which determine the ranges of product positions based 
on values of a subset or the whole set of type features. This 
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kind of constraint takes into account tbe time/timing require- 
ments to operate on certain products or their features (e.g., 
the time frame when workers of certain specific expertise 
will be available or certain resources/equipment can be 
available). 5 

In addition, S may (or may not) also be subject to some 
or all of the following types of soft constraints (i.e., con- 
flicting constraints which cannot be satisfied simultaneously 
and completely): 

A. Feature-based distance equations: a set of equations 10 
which determine product distances in the sequence based on 
values of a subset or the whole set of type features. This kind 
of constraint often characterizes the need to either group 
together or spread products with certain features in a 
sequence for efficient processing (e.g., products requiring is 
the same part are not put too close in a sequence so that there 
will be sufficient time for the worker or process to install the 
part without causing a stop of the sequence at the installation 
point). 

B. Feature -based distance inequalities: a set of inequali- 20 
ties which determine the ranges of product distances in the 
sequence based on values of a subset or the whole set of type 
features. This kind of constraint usually takes into account 
the fact that sometimes products do not have to go through 
a certain process strictly sequentially, rather the process may 25 
be applied to products out-of-order so long as the substituted 
product possess the same or similar features of the replaced 
product. 

For a given feasible and valid sequence, a cost is com- 
puted to measure the violation of each soft constraint or each 30 
type of soft constraints in the sequence, and tbe total cost C 
of the entire sequence is a combination of such individual 
costs. C can be formulated as a weighted sum of individual 
costs, where each weight determines the contribution of the 
corresponding cost to the total cost C. The method of the 35 
present invention then finds the optimal or nearly optimal 
sequence, that being the best sequence which satisfies all 
hard constraints and minimizes the total cost C for violation 
of soft constraints. 

The present invention utilizes an EC algorithm charac- 40 
terized by the following components: 

Chromosome representation: A population of individual 
chromosomes, each chromosome being an ordered list rep- 
resenting a feasible and valid product sequence (see FIG. 1), 
wherein each element in the list corresponds to a product in 45 
the sequence. The length of a chromosome is N, the total 
number of products in a sequence. 

Fitness evaluation: The fitness of a chromosome (i.e., a 
sequence) is measured by the total cost C (as discussed 
above) for violating soft constraints. Thus, the fitter a 50 
chromosome, the lower its total cost. 

Initialization: The initial population of chromosomes 
must include some randomly generated valid sequences (i.e., 
only sequences which satisfy all hard constraints). The 
population can consist of only randomly generated valid 55 
sequences, or it can also include some pre -determined 
sequences based on problem-specific heuristic knowledge 
("imported" sequences). 

Genetic operators: Genetic operators are used to alter 
chromosomes in order to create new and potentially fitter 60 
chromosomes. Two operators are preferred: one mutation 
operator and one crossover operator. The mutation operator 
performs the following operation on a single chromosome 
(i.e., a single sequence): first, randomly select two positions 
where the products are not of the same type; if swapping the 65 
two products does not violate any hard constraint, the 
products are swapped; otherwise, either two new positions 
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are selected and the process repeated, or alternatively the 
process is aborted (see FIG. 2). Note that operation of the 
mutation operator does not cause any violation of the hard 
constraint of production requirements. 

The crossover operator operates on two chromosomes to 
generate two new chromosomes (called offspring). It starts 
by randomly selecting a sequence position and checks if the 
corresponding products in the two sequences are of the same 
type. If they are not, the corresponding products are 
swapped to produce two oflspring. Note that as the swapping 
occurs at the same position, the feature-based position and 
position range constraints are not violated. Since the swap- 
ping inevitably violates the hard constraint of production 
requirements in the two oflspring by decreasing the number 
of one type of product by 1 and by increasing the number of 
the other type of product by 1 at the same time, another 
swapping is needed to repair the offspring. This second 
swapping (referred to as a "Repair Operation") is likely to 
happen between products at different positions, as shown in 
FIG. 3, but again, it will not violate the feature-based 
position or position range constraints as in the first swap- 
ping. 

Reproduction: Reproduction refers to the process of gen- 
erating new chromosomes. In the present invention, this 
process consists of first selecting a genetic operator, and then 
selecting either one (if the mutation operator is selected) or 
two chromosomes (if the crossover operator is selected) for 
reproduction. Each operator has a probability, and a roulette 
wheel is constructed based on the operator probabilities. The 
probability value of an operator can either be pre-determined 
based on problem-specific knowledge, or can be adjusted 
during the evolution process based on the operator's use- 
fulness (i.e., performance) in past generations. An operator 
is selected by "spinning" the wheel. 

To facilitate the selection of chromosomes, the initial 
population of chromosomes are sorted in the ascending 
order of their fitness (i.e., cost) values. A roulette wheel is 
built with the size of the slice for each chromosome pro- 
portional to its rank in the sorted list. Then each time a 
selection is done by "spinning" the wheel a chromosome is 
selected with a probability proportional to its rank. After the 
genetic operation, the newly generated offspring (or one of 
the two offspring generated from crossover with repair) is 
evaluated (i.e., its fitness value is calculated) and is inserted 
into the sorted population based on its fitness value; one of 
the worst chromosome in the population is then discarded to 
maintain the original population size. Such a population now 
represents a new generation and remains sorted. 

Overall algorithm: The algorithm starts with an initial- 
ization process in which the population is generated. The 
population is then evaluated as sorted as described above. 
The reproduction process described above is then repeated 
until either a set of termination conditions are satisfied, or a 
pre-determined amount of time has elapsed. The algorithm 
flow chart is as shown in FIG. 4. 

Detailed Description of an Illustrative Embodiment 
The nature and variants of the present invention are 
illustrated by the following example. Although the example 
is limited to one industry specific embodiment of the 
invention, the invention itself should not be construed as 
being so limited. Additionally, (and it should be apparent) 
various variations and modifications may be made to the 
invention, with the attainment of some or all of the advan- 
tages of the invention. It is the subject of the appended 
claims to cover these and such other variations and modi- 
fications as come within the true spirit and scope of the 
invention. 
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The Vehicle Sequencing Problem 

The vehicle sequencing problem represents a special 
instance of the general sequencing problem described above. 
The primary objective of vehicle sequencing is to develop a 
vehicle assembly sequence which is preserved throughout 
the body shop, paint, and final assembly processes, is 
unlikely to be disrupted, and which simultaneous minimizes 
the direct costs associated with labor, parts, inventories, and 
paint costs, while increasing equipment and floor space 
utilization. 

Recently, car sequencing has taken on greater significance 
as the complexity of vehicle assembly has increased due to 
automotive manufacturers' desire to accommodate consum- 
ers' individual preferences vis-a-vis car exterior colors and 
features, such as sun roofs, car interior colors, fabrics and 
options. 

The Nature of Vehicle Sequencing 

Currently, automobile manufacturing companies offer 
customers a wide variety of vehicle configurations within 
each model. The possible combinations of body styles, 
powertrains, interior and exterior colors, and free-standing 
options can number in the tens to hundreds of thousands of 
unique vehicles. This presents a very complex scheduling 
problem when determining the ideal sequence of vehicles to 
be built on a given day. However, it is an important problem 
to solve, since an optimum sequence will reduce direct labor, 
parts inventories and paint costs, while increasing equip- 
ment and floor space utilization. 

In the past, off-line repairs of defects in the upstream body 
shop created an unpredictable sequence of vehicles for the 
paint shop, while off-line paint defect repairs resulted in an 
even less predictable bank of vehicles for the final assembly 
(trim and chassis) line sequence. Poor sequences entering 
the paint bank cause a significant waste of materials. For 
instance, each time the color of a vehicle changes from its 
predecessor in the enamel paint booth, the previous paint 
color must be purged from the paint system gun, wasting 
paint and cleaning solvent. Poor sequences can also result in 
the occurrence of unnecessary costs in the final assembly 
line. The cost of poor sequences with respect to high labor 
value options is direct labor. For example, consider an 
assembly line which produces sixty vehicles per hour and 
contains a moonroof installation station. For a randomly 
arranged sequence of vehicles, if each installation requires 
1.5 minutes of direct labor by two workers, a second worker 
is needed in the moonroof station to stay within the 1 minute 
of cycle time. In a "good" assembly sequence, at least one 
non-moon roof vehicle will be spaced between any two 
moonroof vehicles, such that one worker will be able to keep 
up with the workload and return to the beginning of his 
station after each installation. Good sequences also require 
less floor space per individual station because workers are 
not forced as far out of their station by the needs of 
consecutive high labor value jobs. The sequencing efficien- 
cies are lost when the optimal manufacturing sequence is 
disrupted by missing vehicles at the point where units are 
also moved from the paint bank to the start of the final 
assembly line. Finally, an unpredictable sequence requires 
the inventory of parts to account for all possible vehicle 
configurations. 

These types of inefficiencies can be avoided using the 
method of the present invention. For instance, with the 
optimized sequencing solution of the present invention in 
place, suppliers can ship the exact parts at the exact time 
needed and significantly reduce inventory holding costs. 
Additionally, since units stored in the paint bank have no 
powertrain, trim or options, and are distinguishable only by 
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their body-in-white (BIW) characteristics and paint color, 
the present invention reduces inefficiencies by providing for 
substitution between any missing unit and another unit in the 
paint bank with the same BIW and color but a later sequence 
5 number. The missing unit then gains additional time to arrive 
in the paint bank before it causes a break in the vehicle 
sequence. 

The combination of BIW (e.g.,. sedan/wagon, two or four 

10 door, moonroof, and seating configuration) and paint color 
(e.g., body color and any two-tone accent color or paint 
stripe) is called a painted body. Depending on the vehicle 
line there can be up to a thousand unique painted bodies. To 
facilitate substitution, the method of the present invention 

15 provides for a "back-up" for each vehicle consisting of an 
identical painted body in the paint bank at the time that it 
must be moved to the final assembly line. To do so, requires 
spacing identical painted bodies at a fixed interval which 
relates to the paint bank size. [Substitution has cost benefits 

20 resulting from smaller paint banks and less inventory in the 
paint banks, as well as optimized in-line vehicle 
sequencing.] Painted body spacing, however, adds a great 
deal of complexity to the sequencing problem, since the 
effect is to add one constraint for each unique painted body. 
For a typical plant, this will increase the number of con- 
straints from less than 20 to over 100. The present invention, 
however, provides a feasible method for sequencing of this 
high level of complexity. 

30 Representation 

The product here is a vehicle, and the type of the vehicle 
is determined by the following features: body type, paint 
type/color, and features characterizing option types (such as 
radio, car phone, seat cover, etc.). A customized vehicle type 

35 is then described by a tuple of such features, and each set of 
feature values describes a unique vehicle type. Thus, the 
problem may be represented as follows: 
Given N cars of M types, which 'require a total of K 

40 options, as specified by 

(g if car type / requires option k of grade g 
0 otherwise 

45 

where j=l, .... M and k»l, . . . , K, find a schedule S as a 
sequence of the N cars, satisfying the hard constraints: (1) 
production requirements; (2) fixture constraints; and (3) 
rotation range constraints; while optimizing the following: 
50 (1) optional spacing; (2) painted-body spacing; and (3) paint 
blocking. 

Each vehicle type j . . . , M, is determined by a tuple 
of attributes (bj, pj, pbj, Oj), where 

55 bj is the index of the car body type, 
pj is the index of the paint type, 
pbj is the index of the painted-body type, and 
Oj is a set of option-grade pairs as defined by the function 

Production requirements, fixture constraints, and rotation 
range constraints are three types of hard constraints often 
considered in a real-world vehicle sequencing problem. The 
first, production requirements, is as described in the general 
65 problem formulation earlier, and can be formulated in the 
problem as Prj cars for car type j, where j=l, . . . , M. Note 
that 
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body. The painted-body spacing constraint ensures that there 

m is always at least one substitute in the paint bank for any 

n = Yj pr J- painted body accidentally missing from the sequence at the 

j-i scheduled time of its painting. This substitution allows for 

5 efficiency to be gained by preventing the break of sequence 

t, . . • . u« u • c j. .u«. due to the missing unit and also allows for additional time 

The second constraint, which is referred to as the fixture e tU . . . . , . , . , ~ , . 

. . . . ' - . if. t_ j for the missing unit to arrive at the paint bank. The deter- 

constraint, is a special c« of the general feature-based mma tion of the distance bounds (d M&l and d max ) depends on 

position equations constraint. The fixture constraint requires {h& &[zt of the - ( bank — «•«' 

that a vehicle of certain body type (e g., sedan or wagon or p am ted-body spacing can be formulated in the problem 

different car model) can only be placed at some specific io as: n € [UU ] vehicles of identical painted bodies should be 

positions in the sequence. The fixture constraint can be m the paim bank of size A at any time violation incurs a 

formulated in the problem as a fixed body type sequence x 3 cost N (i j) is the number of vehicles of painted-body j in 

x 2 . . . x„, where x, e{l, . . . , B} for i-1, . . . , N, is required, lhe A vehicles starting from position i. 

where B is the total number of body types. Th c cos t associated with j at i is, thus; 

The third constraint, referred to as the rotation range is 
constraint is a special case of the general feature -based 

position inequalities constraint. The rotation range con- c 

straint requires that vehicles with certain feature values must pi J ~ 
be produced within a certain time frame, which can be 

translated as that they must be placed within a certain range 20 

of positions in the sequence. The rotation range constraint anc j tota i ^st for painted-body spacing: 
can be formulated in the problem as:: i yl <r(i)<i- 2 where r(j) 

is the position of the car type j, and l<i /1 <i /2 <N. N 

The hard constraints are consistent with one another and c p = Yj h i c P 1 ^ $ 

can all be satisfied at the same time. 25 >-i 

The three types of soft constraints, optional spacing, 

painted-body spacing, and paint blocking, are generally whefC . ^ thc wdght for pain ted-body type j an d contains 

included in real-world vehicle sequencing problems. The painted-body type information for position i. 

option spacing constraint is a special case of the general pa i nt -blocking constraint is a special case of the 

feature-based distance inequalities constraint. It specifies, in 30 genera i feature -based distance equation constraint. It speci- 

this instance, that any two vehicles sharing certain feature ^ tna t vehicles of the same exterior paint color be grouped 

values should be separated by a minimum distance, i.e., the together, i.e., d»l, where d is the smallest distance between 

smallest distance d between such two vehicles is greater than two identical painted bodies. This constraint minimizes the 

a d mf „(i.e., d>d min ). For example, if two vehicles require the financial cost associated with paint gun purge every time 

same type of radio and no other vehicle between them in the 35 paint colors are switched. This constraint can be formulated 

sequence requires that type of radio, the distance between in the problem as: V vehicles of the same paint type are 

them should allow sufficient time for installation of the radio preferred to form a consecutive subsequence (block). Vio- 

on one vehicle before the second vehicle arrives for instal- lation incurs a cost. If N m is the length of the m-th same- 

lation of the same radio. paint subsequence in the vehicle sequence, then the associ- 

Optional spacing can be formulated in the problem in the 40 ated cost is: 
following manner: if there are N* vehicles requiring option 

k in the sequence of N vehicles, the ideal spacing for option c _ j l if N m %v > 0 



10 if/V„ 



k is N/N*. Less spacing incurs a cost. Cost for option k, thus, \ 0 if N m %v = 0 

would be: 

45 

#Woto;wu where N„ % V returns the remainder when N m is divided by 

c v y" f ^ gaj * -octuah + n 3 V, and the total cost for paint blocking is a weighted sum of 

01 " 2-j V ideal* J costs associated with individual same-paint subsequences: 

50 _ V 

.and total cost for optional spacing is a weighted sum of costs c ? b - Zj w » c *l m ) 

for individual options: ' w=1 

* where D is the total number of paint changes. 

°o = 2j a * c « (A ) 55 Clearly the soft constraints described above conflict with 

one another, and it is difficult or even impossible to satisfy 
any one of them completely. Accordingly, violation of a soft 
where a fc is the priority/weight for option k and K is the total constraint is allowed at a pre-determined cost, 
number of options. Given a vehicle sequence, as in the general formulation of 

The painted -body spacing constraint is also a special case 60 the sequencing problem described earlier, the total cost 
of the general feature-based distance inequalities constraint. associated with the soft constraints is a weighted sum of 
It specifies both a minimum and a maximum distance individual costs, where each weight determines the contri- 
between two vehicles of the same painted-body type, i.e., the button of the corresponding individual cost of the total cost, 
combination of a basic body type (without powertrain, trim, The fitness of each chromosome is thus a function of the cost 
or options) and the paint color. For each painted-body type, 65 function measuring the degree of violation of soft con- 
such a constraint is in the form of d m(>t <d<d ma;c , where d is strain ts: Cost=c 0 C 0 +c a Cp+Q C pb . The coefficients c t -, i=0, 
the smallest distance between two vehicles of that painted 1, 2 can characterize the priorities of the three kinds of costs. 
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The problem can now be solved with the algorithm of the 
present invention to find the best sequence of vehicles which 
satisfies all hard constraints and minimizes the total cost for 
violation of soft constraints. 

The algorithm of the present invention was tested on 
sample data sets provided to the inventor by a major United 
States automobile manufacturing company. The results of 
the test runs are presented in the Examples below. 



Example One (Data Set 1) 

Data Set 1: 512 vehicles of 100 types, 1 body type, 12 
paint types, 28 painted body types, and 9 options. 

TABLE 1 





System Parameters 










Mutation 


20 


Population Size 


Crossover Probability 


Probability 




5 


0.6 


0.4 





Results for Data Set 1 



TABLE 2 



Total time 


generation - 10,000 


Cost With Optional Spacing Only 
All costs 


about 2.5 min. 
about IS min. 


TABLE 3 


Costs with ootionat spacina only 


Best Initial 
Initial Population Result 


Best Final Result 
(generation = 20,000) 


Randomly Generated 333.068 
Included Sample* 25.080** 


23.684 
8.967 


•a pre-dctennincd "good" sample sequence is 
randomly generated initial population. 
• *is also the cost of the sample sequence. 


included in the otherwise 


TABLE 4 




Costs (randomly Ecnerated initial Dooulation) 


Best Initial 

Costs (weights) Result 


Best Final Result 
(generation = 20,000) 


Optional Spacing (1) 353.52 
Painted Body Spacing (0.1) 8864 
Paint Block (1) 450 


46.45 
7755 
294 



14 



Results for Data Set 2 
Total time: about 5 minutes for 10,000 generations. 

TABLE 5 



Initial Population 



Costs (with optional spacing only) 

Best Final Result 
Best Initial Result (generation = 20,000) 



Randomly Generated 
Included Sample** 5 



5.6 x 10 16 
6.45 x lO 15 *" 5 



5.67 x 10 15 
6.11 x 10 15 



pre-determined "good" sample sequence is included in the otherwise 
randomly generated initial population. 



( " 5 is also the cost of the sample sequence. 



15 



50 



55 



Example Two (Data Set 2) 60 

The system parameters for this run were as set forth in 
Table 1 in Example One. 

65 

Data Set 2: 852 vehicles of 167 types, 2 body types, 13 
paint types, 1 painted body type, and 20 options. 



TABLE 6 





Costs (with paint blockins only) 






. Best Final Result 


Initial Population 


Best Initial Result 


(generation - 10,000) 


Randomly Generated 


741 


482 


Included Sample 


471* 


385 



25 



30 



35 



40 



45 



*is also the cost of the sample sequence. 

The algorithm of the present invention was also imple- 
mented and used in one real-world vehicle manufacturing 
plant with excellent results: the number of units in the paint 
bank without an identical painted body back-up being 
reduced by an average of 36%, while the rest of the 
scheduling objectives were also achieved. 

It will be appreciated that many modifications may be 
made to the system described above without departing from 
the scope of the present invention. For example, possible 
modifications include: 

A. Modifications to the way the values of the system 
parameters are assigned, such as the population size, the 
operator probabilities, the coefficients in the fitness measure, 
etc. While such values may be determined in an ad hoc way 
based on experience, the values assigned to system param- 
eters can also be adapted based on their influence to the 
system and the system performance, which indirectly 
reflects the characteristics of the specific problem being 
attacked. Such a self- adapting system allows use of the 
system without requiring the users to be experts with 
insights of system and even the problem. One example of a 
self-adapting version of the present invention is the use of 
weighted sum of costs related to known goals. Different 
assignments of these weights would significantly affect the 
behavior of the optimization system. 

B. Use of additional genetic operations. Existing genetic 
operations can be incorporated into the present invention, 
for instance, heuristic strategies for initialization (note that 
the preferred embodiment uses random initialization), and 
dynamic termination conditions. 

Having described the exemplary embodiments of the 
invention, additional advantages and modifications will 
readily occur to those skilled in the art from consideration of 
the specification and practice of the invention disclosed 
herein. Therefore, the specification and examples should be 
considered exemplary only, with the true scope and spirit of 
the invention being indicated by the following claims. 

What is claimed: 

1. A computer implemented method for generating an 
optimized sequence of "N" number of items, where said 
items are of "M" number of types with a fixed number ("N") 
of each type being desired and each item type comprising an 
array ("Q") of features, wherein said sequence of items is 
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optionally constrained by one or more of the constraints, 
wherein each of said one or more constraints is individually 
designated as either a hard constraint which cannot be 
violated, or as a soft constraint which can be violated at a 
predetermined cost; said method comprising: 5 
generating an initial population of chromosomes, wherein 
each chromosome represents a feasible sequence of 
items, feasibility depending on satisfaction of all of 
said hard constraints; 
associating a fitness value with each chromosome; 10 
sorting said chromosomes based on the fitness value 

associated with each chromosome; and 
applying iteratively to the population of chromosomes a 
reproductive process, said reproductive process com- 15 
prising application of a selected genetic operator to a 
selected one or more chromosomes to cause generation 
of one or two offspring said reproductive process being 
continuously run until the fitness value for the best 
chromosome satisfies one or more known criteria, 20 
wherein one or more genetic operators available for 
selection is assigned a probability of selection value 
and a roulette wheel scheme and a roulette wheel 
scheme utilizing these probability of selection values is 
used to choose operators. 2 5 

2. The method of claim 1, wherein said items comprise 
products for manufacture. 

3. The method of claim 1, wherein said types are distinct 
types. 

4. The method of claim 1, wherein said features are 30 
distinct features. 

5. The method of claim 1, wherein said constraints 
comprise one or more constraints selected from the group 
consisting of: a production requirement for each item type; 
feature-based position equations; and feature-based position 35 
inequalities. 

6. The method of claim 1, wherein said fitness value is a 
function of the predetermined cost associated with the 
degree of violation of each of said soft constraints. 

7. The method of claim 1, wherein said reproductive ^ 
process further comprises: (1) selection of said genetic 
operator, (2) selection of one or two chromosomes, the 
number of chromosomes to be selected correlating with the 
selected genetic operator, (3) application of the selected 
genetic operator to the selected one or two chromosomes to 45 
cause generation of one or two offspring, (4) insertion of one 
offspring chromosome into the sorted population, and (5) 
discard of one of the least desirable chromosomes in the 
population. 

8. A computer implemented method for generating an 50 
optimized sequence of "N" number of products for 
manufacture, where said products are of "M" number of 
distinct types with a fixed number ("Nt") of each type being 
desired and each product type comprising an array ("0") of 
distinct features, wherein said manufacture is optionally 55 
constrained by one or more of the following constraints: the 
production requirement for each product type, feature-based 

' position equations, and feature-based position inequalities, 
wherein each of said constraints is individually designated 
as either a hard constraint which cannot be violated, or as a 60 
soft constraint which can be violated at a predetermined 
cost; said method comprising: 
generating an initial population of chromosomes, wherein 
each chromosome represents a feasible sequence of 
products of various types for manufacture, feasibility 65 
depending on satisfaction of all of said hard constraints; 
associating a fitness value with each chromosome; 



sorting said chromosomes based on the fitness value 
associated with each chromosome; and 

applying iteratively to the population of chromosomes a 
reproductive process, said iterative process being con- 
tinuously run until the fitness value for the best chro- 
mosome satisfies one or more known criteria or until a 
pre-determined time has elapsed, wherein said one or 
two chromosomes are selected using a roulette wheel, 
wherein said roulette wheel comprises a probability 
distribution derived from the relative ranking of the 
fitness values associated with each chromosome such 
that the probability for an individual chromosome to be 
selected is proportional to its relative ranking. 

9. The method as set forth in claim 8 wherein said genetic 
operator comprises one of the of the following: a mutation 
operator and a crossover operator. 

10. The method as set forth in claim 9 wherein one 
chromosome is selected if the genetic operator is a mutation 
operator. 

11. The method as set for in claim 9 wherein two 
chromosomes are selected if the genetic operator is a cross- 
over operator. 

12. The method as set forth in claim 8 wherein said 
genetic operator is a crossover operator. 

13. The method as set forth in claim 12 wherein applica- 
tion of said crossover operator comprises the steps of 

selecting two parent chromosomes from the population, 

randomly selecting a position index, said position index 
representing the location of a single product 

comparing between the two parent chromosomes the 
single product located at said position index, and 

if said two single products located, one in each parent 
chromosome at said position index, are not identical to 
one another, generating two offspring chromosomes 
identical to two parent chromosomes with the excep- 
tion that the two single products located at the position 
index are swapped; 

locating within each of the two offspring chromosomes 
the first sequential product that is identical to the 
swapped-in product; and 

swapping between the two offspring chromosomes said 
sequential products. 

14. The method as set forth in claim 8 wherein said 
genetic operator is a mutation operator. 

15. The method as set forth in claim 14 wherein applica- 
tion of said mutation operator comprises the steps of ran- 
domly selecting two position indices, each position index 
representing the location of a single product, comparing the 
single product located at each position index, and if said 
single products are not identical, interchanging the single 
products so long as the resulting sequence satisfies all hard 
constraints. 

16. The method as set forth in claim 8 wherein application 
of the selected genetic operator comprises the steps of 
randomly selecting two position indices, each position index 
representing the location of a single product, comparing the 
single product located at each position index, and if said 
single products are not identical, interchanging the single 
products so long as the resulting sequence satisfies all hard 
constraints. 

17. The method as set forth in claim 8 wherein application 
of the selected genetic operator comprises the steps of 

selecting two parent chromosomes from the population, 
randomly selecting a position index, said position index 

representing the location of a single product 
comparing between the two parent chromosomes the 

single product located at said position index, and 
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if said two single products located, one in each parent 
chromosome at said position index, are not identical to 
one another, generating two offspring chromosomes 
identical to two parent chromosomes with the excep- 
tion that the two single products located at the position 
index are swapped; 

locating within each of the two offspring chromosomes 
the first sequential product that is identical to the 
swapped-in product; and 

swapping between the two offspring chromosomes said 
sequential products. 

18. The method of claim 8 in which each of said one or 
more genetic operators available for selection is assigned a 
probability of selection value and a roulette wheel scheme 
utilizing these probability of selection values is used to 
choose operators. 

19. The method of claim 18 wherein the probability of 
selection values are assigned in such a way that all operators 
are equally likely to be selected, 

20. The method of claim 18 wherein the probability of 
selection values are assigned in such a way that the cross- 
over operator is less likely to be selected. 

21. The method of claim 18 wherein the probability of 
selection values are assigned in such a way that the cross- 
over operator is more likely to be selected. 

22. The method of claim 18 in which the probability of 
selection value assigned to each operator varies from itera- 
tion to iteration relative to the usefulness of each operator in 
previous iterations. 

23. The method as set forth in claim 8 in which the initial 
population of chromosomes comprises randomly generated 
chromosomes. 

24. The method as set forth in claim 8 in which the initial 
population of chromosomes comprises imported chromo- 
somes. 

25. A computer implemented method for generating an 
optimized sequence of "N" number of items, where said 
items are of "M" number of types with a fixed number ("N,") 
of each type being desired and each item type comprising an 
array ("Q") of features, wherein said sequence of items is 
optionally constrained by one or more of the constraints, 
wherein each of said one or more constraints is individually 
designated as either a hard constraint which cannot be 
violated, or as a soft constraint which can be violated at a 
predetermined cost; said method comprising: 

generating an initial population of chromosomes, wherein 
each chromosome represents a feasible sequence of 
items, feasibility depending on satisfaction of all of 
said hard constraints; 

associating a fitness value with each chromosome; 

sorting said chromosomes based on the fitness value 
associated with each chromosome; and 

applying iteratively to the population of chromosomes a 
reproductive process, said reproductive process com- 
prising application of a selected genetic operator to a 
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selected one or more chromosomes to cause generation 
of one or two offspring said reproductive process being 
continuously run until the fitness value for the best 
chromosome satisfies one or more known criteria, 
5 wherein said genetic operator comprises a mutation 
operator, comprising the steps of randomly selecting 
two position indices, each position index representing 
the location of a single product, comparing the single 
product located at each position index, and if said 
10 single products are not identical, interchanging the 
single products so long as the resulting sequence sat- 
isfies all hard constraints. 
26. A computer implemented method for generating an 
optimized sequence of "N" number of items, where said 
15 items are of "M" number of types with a fixed number ("N,") 
of each type being desired and each item type comprising an 
array ("Q") of features, wherein said sequence of items is 
optionally constrained by one or more of the constraints, 
wherein each of said one or more constraints is individually 
20 designated as either a hard constraint which cannot be 
violated, or as a soft constraint which can be violated at a 
predetermined cost; said method comprising: 
generating an initial population of chromosomes, wherein 
each chromosome represents a feasible sequence of 
25 items, feasibility depending on satisfaction of all of 
said hard constraints; 
associating a fitness value with each chromosome; 
sorting said chromosomes based on the fitness value 
associated with each chromosome; and 
30 applying iteratively to the population of chromosomes a 
reproductive process, said reproductive process com- 
prising application of a selected genetic operator to a 
selected one or more chromosomes to cause generation 
of one or two offspring said reproductive process being 
35 continuously run until the fitness value for the best 
chromosome satisfies one or more known criteria, 
wherein said genetic operator comprises a crossover 
operator, comprising the steps of: 
selecting two parent chromosomes from the population, 
40 randomly selecting a position index, said position index 
representing the location of a single product 
comparing between the two parent chromosomes the 

single product located at said position index, and 
if said two single products located, one in each parent 
45 chromosome at said position index, are not identical 

to one another, generating two offspring chromo- 
somes identical to two parent chromosomes with the 
exception that the two single products located at the 
position index are swapped; 
50 locating within each of the two offspring chromosomes 
the first sequential product that is identical to the 
swapped-in product; and 
swapping between the two offspring chromosomes said 
sequential products. 

55 
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E-Coin), the Receiver includes a "hint generation value" in 
the request, and from the hint generation value, a "hint 
value" is derived and recorded on a signing transcript. The 
hint generation value is essentially an encrypted version of 
the request submitted from the Receiver to the Signer. When 
a merchant/Verifier transmits deposit signatures correspond- 
ing to spent E-Coin to be deposited, the transmitted signa- 
ture is decrypted and blinded by the Signer in the same 
manner as that used to create the hint value. Thus, the 
encrypted incoming deposit signature from the merchant/ 
Verifier should match the hint value stored on the signing 
transcript, confirming that the E-Coin is valid without 
revealing any identifying information about who spent the 
E-Coin, i.e., anonymity is preserved. If the incoming 
encrypted deposit signature does not match a hint value in 
the signing transcript, the bank immediately knows that 
counterfeit E-Coin is being circulated and can take the steps 
necessary to stop any further illicit transactions and attempt 
to identify the source of the corruption. 
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DIGITAL SIGNATURES HAVING 
REVOKABLE ANONYMITY AND IMPROVED 
TRACEABILITY 

FIELD OF THE INVENTION 

This invention relates to the field of authentication of 
electronic data, and more specifically, to producing digital 
signatures that allow for revokable anonymity and the ability 
to detect the unauthorized use of a secret key without 
compromising anonymity requirements. 

DESCRIPTION OF THE RELATED ART 

Electronic commerce (E-Commerce) is one of the fastest 
growing segments of the Internet. All aspects of monetary 
transactions are being carried out electronically including 
banking, investing, purchase and sales, and the like. While 
the benefits of E-Commerce are many, certain precautions 
must be taken to prevent abuse and to ensure that the privacy 
of the participants is not compromised. Accordingly, authen- 
tication techniques utilizing "electronic signatures'* and 
"secret keys" have been developed so that assurances can be 
made that the transactions requested are legitimate transac- 
tions. Many examples of such techniques can be found in the 
prior art (see, for example, M. Jakobsson and M. Yung, 
"Applying Anti-Trust Policies to Increase Trust in a Versatile 
E-Money System," Advances in Cryptology-Proceedings of 
Financial Cryptography '97, pp. 217-238. 

In view of the need for protection of privacy, much of the 
research in the field of E-commerce has been focused on 
developing payment or signature schemes with revokable 
anonymity. Such schemes facilitate general anonymity with 
respect to transactions, but allow details of a particular 
transaction or user to be identified under appropriate cir- 
cumstances (e.g., pursuant to a court order). For example, a 
set of "trustees" might possess the ability to remove the 
anonymity of a given user or transaction when all agree that 
there is reason to believe that the user is committing a crime 
or that a particular transaction is fraudulent. 

"Blinding" is a technique utilizing electronic signatures 
by which the provider of a message for signing, e.g., a bank 
customer, can transform the message to be signed into a 
form which obscures the content of the message. Thus, the 
signer, e.g., a bank, can sign the transformed message and 
return it to the provider of the message, and the provider can 
transform the message in such a way that the result retains 
the digital signature property related to the original message 
content, but the result is not readily associated with the 
transformed message received by the signer. One example of 
such a technique is disclosed in U.S. Pat. No. 4,759,063 to 
Chaum, incorporated herein by reference. 

To understand the known methods of revoking anonymity 
it is necessary to understand the mechanics of electronic 
transactions. For example, a typical electronic transaction 
will involve three participants: a Signer, typically a bank; a 
Receiver, typically a consumer who is a customer of the 
Signer; and a Verifier, typically a merchant who transacts 
business with the Receiver. 

For the purpose of this explanation, presume that a 
Receiver A has $10,000 in an established bank account with 
a Signer bank B. If Receiver A needs conventional cash, he 
or she simply goes into the bank or to an automatic teller 
machine (ATM), makes a withdrawal, and receives the cash 
in hand. If, however, Receiver A wants to have the ability to 
conduct electronic transactions, for example, with merchant 
(Verifier) C, then Receiver A needs to request a withdrawal 
of electronic cash (E-Coin) so that it will be available for use 
on demand. 
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To "withdraw" E-Coin, Receiver A sends a request to the 
Signer bank B and asks the bank to issue, for example, 
$2,000 in E-Coin to Receiver A. This request would typi- 
cally be in the form of an authenticated encrypted e-mail 
5 message which allows the bank to confirm the identity of the 
requester. Signer bank B, after verifying that the funds are 
available, will issue the E-Coin (electronic funds, essentially 
an e-mail), encrypted using conventional encryption 
methods, and bearing a "signature" S which identifies Signer 
10 bank B as the issuer of the E-Coin, The signature S is a 
verification that the bank issued the E-Coin and that it is, 
therefore, acceptable to use for an electronic transaction. 

The Signer bank B keeps daily transcripts, called "signing 
transcripts," of all E-Coin issued (withdrawn). This tran- 
35 script is used to correlate withdrawals with the appropriate 
bank account. It is also used, as discussed below, to verify 
that E-Coin presented to a merchant/verifier is legitimate. 

With the E-Coin now available for immediate spending 
(in this example, $2,000), Receiver A can present some or all 
20 of the E-Coin to Merchant C to transact business. Thus, if 
Receiver A wants to purchase a $200.00 item from Merchant 
C, Receiver A will send an electronic purchase request along 
with an electronic "draft" promising to pay Merchant C 
$200.00 of E-Coin. The electronic draft includes the signa- 
25 ture S issued by the Signer bank B. Merchant C will then 
deliver the item to Receiver A and, possibly at a later time 
and/or date, present the electronic draft to the bank for 
payment. 

3Q Signer bank B keeps a second transcript, called herein a 
"spent E-Coin transcript", which identifies all E-Coin that 
has been deposited by a verifier such as a merchant or a 
payee (if an item is found on this transcript, this indicates 
that the E-coin identified has been spent). The spent E-Coin 

35 transcript gives the bank the ability to track the use of 
E-Coin by a particular bank customer so that assurances can 
be made that a particular bank customer has not "over- 
drawn" an account (the E-Coin is somewhat analogous to a 
checking account). For example, with the spent E-Coin 

4Q transcript the bank can determine that more cash was spent 
than was issued to a particular user (an overdraft) and initiate 
a trace to identify the overspender. 

Used in connection with the signing transcript, the spent 
E-Coin transcript also gives the bank the ability scan for the 

45 circulation of counterfeit E-Coin. By comparing the signing 
transcripts with the spent E-Coin transcripts, the bank can 
identify the existence of counterfeit E-Coin because there 
would be instances of the spending of E-Coin seemingly 
issued by the bank (e.g., bearing the banks electronic 

50 signature) but with no record of issuance in the signing 
transcript. 

While the system described allows for recording and 
tracing of transactions, two basic problems exist. First, the 
correlation process is computationally costly because each 

55 transaction must be "examined" during the correlation 
process, which is a time-consuming task. Second, the system 
provides no anonymity, as the bank has access to complete 
information about the purchasing habits of its customers, 
which is unacceptable. 

60 Recently, a technique referred to as "magic ink signa- 
tures" has been developed to offer revokable privacy and a 
new tracing option. This method is described in detail in 
"Distributed Magic Ink Signatures" by M. Jakobsson and M. 
Yung, Advances in Cryptology-Proceedings of Eurocrypt 

65 '97, pp. 450-464. According to this technique, the Signer 
bank B distributes the responsibility of both signing, tracing, 
and maintenance of detection mechanisms (e.g., the keeping 
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of transcripts) among a subset of smaller "banks" (e.g., generation value m ff ), is decrypted and blinded by the bank 
several isolated computer systems, several different offices in the same manner as was the hint generation value m tf . 
of the bank, a government organization, or a combination Thus, the encrypted incoming deposit signature from the 
thereof), so that no single unit has a complete record of a merchant/Verifier should include a value that matches the 
transaction, but instead several of the smaller banks must 5 hint value stored on the signing transcript, confirming that 
collaborate (i.e., a quorum is required) to trace the transac- the E-Coin is valid without revealing any identifying infor- 
tion. Only after it has been determined that an invalid mation about who spent the E-Coin, i.e., anonymity is 
signature has been obtained (or an overdraft has occurred) preserved. If the incoming deposit signature does not con- 
are the subset of smaller banks given the authority to tain a value that matches a hint value in the signing 
collaborate to revoke the anonymity and identify the trans- to transcript, the bank immediately knows that counterfeit 
action or Receiver. E-Coin is being circulated and can take the steps necessary 
The above-described magic ink technique allows a tighter to stop any further illicit transactions and attempt to identify 
control over tracing by allowing suspicions to be verified the source of the corruption. Further, since the incoming 
without divulging any specific information about the signer, encrypted deposit signature will contain a value that matches 
receiver, or verifier. Using the magic ink technique, three « the hint value on the signing transcripts in the case of a valid 
tracing options are available, namely (1) by tracing the transaction, tracing time (e.g., for tracing of overdrafts) is 
identity of the spender from a particular unit of E-Coin; (2) significantly reduced because the hint value will identify the 
by tracing a particular unit of E-Coin from the identity of a location of the appropriate record in the transcript and thus 
spender; or (3) by comparing one particular unit of E-Coin an exhaustive, item-by-item search of the transcript is 
with the identity of one particular holder of E-Coin issued by 20 avoided. 

the bank. Tracing options (2) and (3) have computational BRIEF DESCRIPTION OF THE DRAWINGS 
costs that are independent of the number of signatures that 

have been generated; thus they can be accomplished effi- FIG. 1 is a flowchart of the hint generation process in 
ciently. However, tracing option (1), tracing the identity of accordance with the present invention; and 
a spender from a particular unit of E-Coin, has an expected 25 fig. 2 is a flowchart of the operation of the present 
computational cost which is linear in relation to the number invention to monitor transactions, 
of generated signatures. This relationship between the num- 
ber of signatures and the cost of tracing raises a significant DETAILED DESCRIPTION OF THE 
practical concern, since tracing option (1) is likely to be the PREFERRED EMBODIMENT 
most commonly-used technique, given that this technique 30 pjQ j ^ a fl 0WCQart illustrating the basic steps involved 
allows the tracing of overspent funds. Thus, it would be fn gcncrating a hint vahlc mA as dcfinc d above. Referring to 
beneficial to be able to accomplish revokable anonymity nG t at step 102 a Rccciver R generates a message m and 
with traceability by tracing option (1) in a manner in which sends it tQ a Signer bank B ^ raessage m is a reqU est 
the computational cost of doing the trace is less than linear asking the bank tQ igsue E _ cash tQ Receiver R> and the 
with respect to the number of issued signatures. message m includes a signature which identifies Receiver R 

Another benefit of the prior art magic ink signatures i 0 the bank for verification, 

technique compared to other schemes with revokable ano- To blind ^ message mj j t i s split into several portions 

nymity is that it allows the signer/bank to distinguish ^ thc port j ons being sent to different signing servers 

between valid signatures that were produced by the bank ^ according to the "magic ink signatures" method described 

servers, and valid signatures that were produced by another above ^ tnat QO single signing server has the complete 

party holding the signing keys. This is important if there is message m . However, at the same time the entire complete 

a suspicion that the signing keys of the banks have been messa ge m is also sent, in encrypted form (called hint 

corrupted by, for example, an attacker obtaining the Signer generation value m, in encrypted form) from the Receiver to 

bank's secret key, enabling the attacker to create untraceable each s i gn i ng server tnat comprises the Signer, 

counterfeit E ; Coin (called a "bank robbery attack" in the M m ^ s[ fi gi ^ m thercb 

literature). While the magic ink signature technique can act « m]jain £ tbc E . coin \ s rcqU ested, and sends this message 

as a definitive deterrent against attacks aiming to corrupt the nQw gi B , $ ^ 5ack t0 Receiver R 

bank keys, the very high cost of the filtering makes the as M ^ ^ d [n ^ S[ fi d and 

method impractical unless it is certain that the signing keys bUnds ^ ^ ation value and stores [{ on a Si ing 

have been corrupted, i.e., it is only practical to use the Tnwcd x ^ the signed message m as hint value m 

method for confirmation and/or correction oi the problem . . ..... 

it _ iL c * j * 4 • r,L ui According to the present invention, the hint generation 

after it occurs rather than for early detection of the problem. to r „ . , , , , n • j • 

3 r values m tf are voluntarily introduced by the Receiver during 

SUMMARY OF THE INVENTION lhe initial si S nm g session (the withdrawal). The hint values 

55 m^ are used to efficiently trace from a signature to a signing 

The present invention is an improvement upon the magic session. Since the hint generation values m„ are voluntarily 
ink signature scheme. According to the present invention, submitted by the Receiver there are no controls on their 
when a Receiver makes a request m to a Signer (e.g., a bank correctness. However, a Receiver would have no reason to 
customer asks the bank to issue E-Coin), the Receiver submit an incorrect hint generation value me, since no 
includes a "hint generation value" m e . The hint generation so benefit will be gained by doing so and since, if necessary, the 
value m e is essentially an encrypted version of the request m. Signer bank can institute a penalty for submitting an incor- 
II is simultaneously decrypted and blinded by the Signer and rect hint generation value m e . By submitting the hint gen- 
is stored on the signing transcript as a hint value m h . eration value m ei the computational cost for tracing is 

When a merchant/Verifier transmits deposit signatures logarithmic (or less) rather than linear for tracing type (1) 

corresponding to spent E-Coin to be deposited, the trans- 65 described above. If, however, an incorrect hint generation 

milted deposit signature, which includes the encrypted value m e is input, the system can fall-back to the linear-time 

request m (and which is, therefore, equivalent to the hint tracing mechanism of the prior art magic ink solution. 
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FIG. 2 illustrates the operation of the present invention, 
using the hint values to monitor transactions. Referring 
to FIG. 2, at step 202 the Receiver, having possession of the 
E-Cash generated by the Signer in accordance with the steps 
of FIG, 1, generates a purchase request to a particular 5 
verifier/merchant by sending to the verifier/merchant elec- 
tronically the signed message m x along with an authorization 
to allow the verifier/merchant to use a specific portion of the 
E-cash in exchange for a purchased item or service. At step 
204, the verifier/merchant fills the order and, at step 206, the 1Q 
verifier/merchant deposits the spent E-coin by sending a 
deposit message m^ to the bank identifying the amount and 
including the signature attached by the bank when the 
E-coin was issued. 

At step 208, the Signer B decrypts and blinds the deposit 
message m d from the Verifier/merchant using the same 
protocol used to generate the hint value m h and outputs the 
decrypted message to a Deposit Transcript. At step 210, the 
Signer B compares the hint value m h stored on the Signing 
Transcript with the decrypted deposit messages m^ on the 2Q 
Deposit Transcript. For each hint value m A on the signing 
transcript that has a match on the deposit transcript, this 
indicates that it was a valid transaction, and nothing more 
need be done (step 214). 

However, if a situation arises in which there is no match 2 s 
between deposit message tn d from a deposit transcript and a 
hint value m h on the signing transcript, at step 216 a tracing 
is conducted, using well-known prior art techniques, to track 
the unmatched signatures. If at block 218 it is determined 
that the reason for the lack of a match was the submission 30 
of a wrong hint generation value m e , at step 220 the Receiver 
who submitted the wrong hint generation m e value is "pun- 
ished" (i.e., if it was inadvertent, then the Receiver might be 
simply advised of the problem; if has happened repeatedly 
for a particular Receiver, some form of punishment may be 35 
imposed). If, at step 218, it is determined that the submitted 
hint generation value m £ is not wrong, this is an indication 
of a breach in the system, and steps can be taken to stop any 
further damage and corrective measures can be instituted 
(step 222). 40 

As noted above, in the preferred embodiment, the hint 
value m A comprises a decrypted and blinded version of the 
hint generation value m # that the Receiver A sends to from 
the Signer bank B. To assure that the hint value m h is not 
subject to attack, in the preferred embodiment it must not 45 
possible for an adversary corrupting less than a quorum of 
signer/tracer servers to compute the hint value m h corre- 
sponding to a signature (and vice versa), while a quorum of 
signer/tracers can efficiently compute the hint value m h 
given a signature. A public key is divided among a plurality 5 0 
of bank servers, and the bank servers issue a divided 
signature which is assembled on a public key. To speed up 
the process of tracing should the need arise, a list of signing 
sessions having indices sorted with respect to the hint values 
m h is stored; thus, the trace can be directed to a particular 55 
session identified by the hint value m h . 

In order to trace from a signature S to a particular 
signature session, a quorum of tracing servers compute the 
hint value m A from a given signature, and select the corre- 
sponding record from the index of the list of sessions. If no eo 
record is found, this means that either counterfeit E-Coin is 
being circulated or that the Receiver gave an incorrect hint 
generation value m e when the signing session occurred, and 
the process reverts to the linear search method described in 
used in the prior art magic ink signatures technique. 55 

The traditional way to distributively compute and verify 
the correct form of any secret value (which would include 
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the hint value m h of the present invention) involves sharing 
of the hint generation value m, submitted by the Receiver 
among all entities of the distribution. This is found, however, 
to drastically increase the costs incurred in proving the 
validity of a computation. Accordingly, according to the 
present invention, a computation is performed on an 
encrypted transcript. It is well known that it is generally 
difficult to perform computations on encrypted data. 
However, the type of computation (multiplication and 
exponentiation) needed to be performed for, the processing 
of the hint value m h can be done very efficiently on 
encrypted data. This method might therefore be of indepen- 
dent interest, and might be applied to similar situations in 
order to boost the efficiency of other multi-party computa- 
tions. 

The method of the present invention does not affect in any 
way the resulting signature. The signature obtained by the 
Receiver is still a standard DSS signature (on a message of 
a specific format). This facilitates immediate commercial 
use of the present invention with only a nominal increase in 
computational cost and data-storage requirements. 

An example of a process for carrying out the above - 
described method of the present invention is as follows. In 
describing the preferred embodiment of the present 
invention, the following protocols are used. 

Notation: Since different moduli are used at different 
times, [opL is used to denote the operation op modulo z 
where this is not clear from the context. 

ElGamal: ElGamal encryption is used. To encrypt a value 
m using the public key y, the person who performs the 
encryption picks a value Y e w Z uniformly at random, and 
computes the pair (a,b)-(my v ,gj. Thus, (a,b) is the encryp- 
tion of m. In order to decrypt this and obtain m, m=a/b* is 
calculated. 

Mix-Networks: Consider an input list (a ls . . . ,a„). A 
mix-network produces an output which is a random (and 
secret) permutation of (f(a 1} , . . . ,f(aj), for a given function 
f. In the preferred embodiment of the present invention, a 
robust (i.e., such that it produces the correct output given an 
honest quorum of participants) a prior-art mix-network 
decryption scheme is used. Mix networks (described gen- 
erally in "A Practical Mix" by M. Jakobsson, Advances in 
Crypto logy-Proceedings of Eurocrypt '98, pp. 448-461) 
have been used generally in connection with decryption of 
electronic messages but have not been used in connection 
with the detection of electronic bank robberies. 

The Digital Signature Standard (DSS): The underlying 
signature algorithm used in the preferred embodiment is the 
Digital Signature Standard (DSS). 

Key Generation: A DSS key is composed of public 
information p, q, g, a public key y and a secret key x, where: 

1 . p is a prime number of length 1 where 1 is a multiple of 
64 and 512^1^1024. 

2. q is a 160-bit prime divisor of p-1. 

3. g is an element of order q in Z p * . 

4. x is the secret key of the signer, a random number 

5. y^g^ is the public verification key. 

Signature Algorithm: Let m e Z q be a hash of the message 
to be signed. The signer picks a random number k such that 
l^k<q, calculates k" 1 mod q (without loss of generality) k 
and k~ 3 values compared to DSA description are 
interchanged), and sets 

The pair (r,s) is a signature of m. 
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Verification Algorithm: A signature (r,s) of a message m (d) The set of signers Sji e Q distributive ly generate the 

can be publicly verified by checking that r-[[g mj ~ 1 y"~ 1 ] p l r DSS signature on the message using the (shared) public 

Let Q be a quorum of t servers in Sj . . . S 2 , and assume session key p; o is calculated as follows: S, generates o>[ 

that the message m to be signed (corresponding to the *0*+*Pdlr HTECu+xa)^ is interpolated from the 

withdrawal) is of the form m-h" mod p for a generator h. 5 <Vs using a known method for multiplication of secrets, for 

Commonly, this type of scheme is used to sign a public key, example, the method described in R. Gennaro, S. Jarecki, H. 

in which m is this public key, and M is its corresponding Krawczyk, and T. Rabin, "Robust Threshold DSS 

secret key. (For messages M that can be guessed with a s ^ Q u f s > ^™*f « Cryptology-Proceedings of Euro- 

r ui u u*r* 1* *■ f a/u r c cypt 96, pg. 354-371. 

non-negligible probability, an alternative form m- h 2 for ^ e ) The servers send a (a blinded version of the signature 

a random R can be employed.). 10 R ^ R / 

First, the system must be initialized. The servers distnbu- 4, j ne signature Receiver R unblinds the signature: 

lively generate a random secret value ("secret") x for sig- The triple (m,r,s) is a valid DSS signature on 

nature generation, using a (t^n) secret sharing scheme, a m . 

random secret x, for tracing, using a (t rl n) secret sharing The hint value is calculated as follows. For the purpose of 

scheme, and a random secret x, for hint generation, using a 15 this explanation, let x h be a private key distributive^ held by 

(t M n) secret sharing scheme. Each server Si publishes its the tracing servers, and let y^-tg^ be the corresponding 

shares of the public keys yHg*^ y tf =[g*riL> and v /u~[g**r|p> public key. First, the Receiver R calculates an ElGamal 

from which y-[g*]p, y,=[g*,k, and y h =[^ h ]p are interpolated encryption of m, by choosing a ye u Z q and calculates (a,b)= 

in a known manner. Each server then proves knowledge of (mg v , y/)=h M g v , y/). This pair is sent to the distributed 

his secret shares x„ x fi and x hi to the other servers; if a 20 servers. 

particular server fails, then it is replaced and the protocol Next, the servers distributive^ compute hint,-a^,/b. 

restarts. Finally, the signing public key y is published. Then, in order to prove that every server has performed the 

Once the system has been initialized it is ready to conduct correct exponentiation (so that tracing will be possible) the 

a signature session. To conduct a signature session, a session servers run a known protocol for proving valid 

initialization is required. Before starting the signature gen- 25 exponentiation, for example, of the type described in D. 

eration protocol, the Receiver A has to send to the Signer B Chaura and H * VanAntwerpen, "Undeniable Signatures," 

its identity ID and a proof of knowledge of the secret key Advances in Cryptology-Proceedings of Crypto '89, pp. 

corresponding to its identity ID. The distributed signers 212-216. This protocol is a proof that log fl (hint,b)= a log/yJ 

under the control of Signer B designate a session identifi- for a 8 lven quadruple (a,g, (hint.b), y h{ .). Finally, the servers 

cation number, SessionID«ID||l, where lis a number making 30 compute hint as the Lagrange-weighted product of the 

SessionID a unique string so that each trace gives a unique shares hint *' of the servers m the q uorum ( thi s value equals 

answer. [ m **]p tf R did not cheat )- 

To generate the signature for this session, the distributed . Attacks are f ossibIe if il * Possible for an attacker to 

signers prepare a temporary key pair: mscn Previously seen encryptions (e.g., on a withdrawal 

/ ^ . r. . o i- ^ -i- * -u 1 * 3 5 request), or functions of them, and observe what hint is 

(a) The set of signers SJi e Q distnbutively generate a j j * *i_ j \* 1 u . • • 
rivate session ke £ e Z produced. In other words, the attacker could use the hint- 

- x „. „ , t U %- t , ,. . 1- e-i ✓ • generation protocol as an oracle to compute the hint of a 

(b) Signer S, has a share k,- and publishes [g^ (a portion kQQWn si g nature and then generate micit signatures wilD the 

o e pu c session ey;.^ correct hint value. For example, assume an attacker could 

(c) The signers compute r-[g -1]^,, using known methods 40 take a value m - of a known s i gnat ure, encrypt the known 
for computing reciprocals. signature (claiming to withdraw new E-Coin) and send 

(d) r is sent to the Receiver R. (a^Mm'gv, y/) to the distributed signers. Then one "dis- 

2. The Receiver R wants a signature on the message honest" signer (a signer under the control of the attacker) 
mofh^. would watch to see what value hint-m*** is produced: this 

(a) Receiver R generates two blinding factors, a, fie u Z q . 45 would efficiently trace the value m' because everyone, 

(b) Receiver R computes blinded versions of m and including the dishonest participants, get to know the corre- 
ri^ma]^ r=[[r p ] /J ]^ and p=[ral ? . sponding record of the signature. Therefore, to avoid this 

(c) Using a (t s ,nf secret sharing, Receiver R computes scenario, in the preferred embodiment the Receiver must 
fa . . . /O of with public information (g* l . . . g M J and P^ve that it knows the format of the portion of the encryp- 
a (t„n) secret sharing (p, . . . p„) of p, with public so tion that will be raised to the x A power. 

information (y pl . . . y f p "). problem is resolved according to the present inven- 

(d) Receiver R computes an ElGamal encryption of m li p n bv squiring that the solution for the encryption satisfy 
with respect to the public hint key y„: (a,b)=(mg v , yf) % plaintext awareness, a concept that is described, for 
where yeZ example, in Be Hare, Desai, Pointcheval and Rogaway, 

(c) Receiver R sends (/<;, p,-, a, b) to signature generating 55 l™ 4 '™ 5 *™ n 8 Not"* 8 of Security for Public-Key 

server S Encryption Schemes, Advances in Cryptology-Proceeding 

* t, /' . , j .1 * * 4rX of Crypto '98, pp. 26-45. This requirement guarantees that 

3. The tracing values and the signature are generated. .u n • *u * • * ? *• »u- * c 

& . . ^ ° the Receiver knows the plaintext, preventing this type of 

(a) The distributed signers interpolate the tag, tag-Ag"],, attack . Note> lhough ^ lhis musl be done withoul reV ealing 

L v ' J v' 60 any transcript -specific information. 

(b) After having verified the correctness of the computa- This requirement is accomplished by proving knowledge 
tion of (a,b) (using a robust protocol such as that described that (a,b)«h m g v , y/), without leaking any information about 
below), the distributed signers robustly calculate the hint me message m=tvK It is only the value a in the signature 
value hint-aVb, using the method described below. If R did generation protocol that is important; if b is not of the right 
not cheat, the hint value equals NT*. 6S f orm> this only identifies a wrong bint-value which, although 

(c) The hint value is stored in a record along with tag, an inconvenience to the bank, does not constitute a security 
SessionID and ID. breach. 
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The above proof can be established as follows: 

1. Each signer S t , i e Q (which in this case corresponds to 
a participating signing server acting as a verifier) selects a 
value zt»Z q . S ; publishes (h,.,g,.M[h% The pair 
(kg) m (SJluohi]p* [n /eG gJp is sent to the signature Receiver 
R. 

2. The prover (in this case, the signature Receiver R) 
computes a^h^g^, where M is the pre -image of m and y is 
the blinding exponent chosen for the ElGamal encryption. 
The prover sends a commitment com(S) to the verifiers. 

3. Each verifier S,- publishes its value e f and e=[X ieQ e ( ] g is 
sent to the prover. 

4. The prover verifies that (h,|)=([h c ] p ^g € ] /) and halts if 
this is not satisfied (failure to satisfy the equation is an 
indication that a "cheat" has occurred. Otherwise, the prover 
decommits to his commitment of a to the verifiers. 

5. Each verifier checks that a=[a € ]p, and "accepts" if this 
equation is true. 

Tracing techniques (2) and (3) described above are per- 
formed in the same manner as they are performed in the 
prior art and are, therefore, not discussed herein. Regarding 
tracing technique (1), for tracing from a known signed 
message to a particular signing session, the trace is per- 
formed as follows. As mentioned above, there is a secret key 
x for signing, a secret key x, for tracing, and a secret key x h 
for generating a hint. Furthermore, there is a tag^g^, 
[y f p y for tracing purposes. 

Given a description (m,r,s), the tracing servers compute a 
value trace^fm*,,]^ to match with stored hints. Then the 
tracing servers compare traces with the stored hints. If traces 
equals a hint for a particular record, then the signed message 
is deemed to correspond to the signing session of that record. 
If there is no hint value which equals traces, then the tracing 
servers have to calculate (trace a , trace fc )=([tag a rm ~ 1 ] / „ tag fc 
for each potential withdrawal session. Using a known pro- 
tocol for verification of undeniable signatures (e.g., as 
described in the previously mentioned Chaum and 
VanAntwerpen article), the tracing servers verify whether 
loggfMog^^trace^, which holds if the signature corre- 
sponds to the tag. 

As noted above, in addition to economizing the tracing 
techniques available, the present invention also comprises a 
method to detect that the secret signing key has been 
compromised. According to the preferred embodiment, the 
distributed signers periodically blind all hints for signing 
sessions, and, using a mix-network, blind portions of the 
recently "deposited" signatures (signatures from the spent 
E-Coin transcripts), and then verify that each blinded depos- 
ited signature corresponds to a blinded signature on the 
blinded session transcript. If there is any blinded deposited 
signature that has no match, then this signature is unblinded 
and traced. If, during tracing, a matching signature on the 
signing session transcript is not found, this is an indication 
that the signing key has been compromised and the servers 
output a "signing key compromised" message to trigger the 
taking of security measures. If, after unblinding, there is a 
signature transcript found to match the signature on the 
spending transcript, this indicates that the signature simply 
had an incorrect hint value submitted with it, in which case 
appropriate action is taken to punish the Receiver/ 
withdrawer. 

A protocol for accomplishing illicit signature detection is 
as follows: 

1. A list of hints (hinlj, . . . ^inl^), which have been 
generated during signature generation protocols is input to a 
mix server. A blinding exponent £ is distributive ly chosen so 
that £=n t - cG £ t - where £ ( is the share of blinding elements £ 
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held by server S,. The distributed servers robustly compute 
(hint^, . . . hintv) in accordance with well-known proce- 
dures. 

2. (a) The distributed servers have a list (m ls . . . , 
5 m^corresponding to the messages of all of the recently 

deposited signatures (i.e., a spent coin transcript identifying 
those signatures deposited since the last run of the detection 
protocol). 

(b) The distributed servers robustly blind this list with the 
to same blinding exponent ^ as used for the hint list and get 

(m\, . . . ,m\). 

(c) The mix servers perform a mix-decryption on the 
blinded list, resulting in a permutation of the list 
hintj, . . . .hintjt, where hint^m^^. 

15 3, All entries from the blinded spent coin list that exist as 
entries in the blinded hint list are removed. Each remaining 
item hint, is unblinded by computing m^hintj 3/ctrA) . Each 
corresponding signature is traced using the previously 
described tracing methods (1), (2), and/or (3). If the trace is 

20 successful, the receiver of the signature is punished for 
having given the incorrect hint value; if there is an unsuc- 
cessful trace, then the servers output "signing key corrupted" 
message which alerts the bank to take immediate action to 
prevent further counterfeiting. 

25 While there has been described herein the principles of 
the invention, it is to be understood by those skilled in the 
art that this description is made only by way of example and 
not as a limitation to the scope of the invention. For 
example, although the present invention is described in the 

30 preferred embodiment as being applicable in an electronic 
commerce application, it finds application in any situation in 
which there is a need to have anonymous digital signatures 
which are revocable. Accordingly, it is intended by the 
appended claims, to cover all modifications of the invention 

35 which fall within the true spirit and scope of the invention. 
We claim: 

1. A method of conducting electronic commerce between 
a signer, a receiver, and a verifier, utilizing E-coin having a 
digital signature which can be verified as being valid without 
40 compromising the anonymity of the digital signature, com- 
prising the steps of: 

generating E-Coin comprising a digital signature S and a 
message m; 

generating a hint value m h by said signer based on said 
45 message m; 

storing said hint value m A ; and 

confirming said that said E-Coin is valid using said hint 
value m A , 

50 2, A method as set forth in claim 1, wherein said step of 
generating a hint value m h comprises the step of decrypting 
and blinding said message m. 

3. A method as set forth in claim 2 wherein said verifier 
makes a deposit of E-coin by sending a deposited E-coin 

55 value m d to said signer, and wherein said confirming step 
comprises the steps of: 
decrypting deposited E-coin to create a decrypted version 
of message m d associated with said deposited E-coin; 
and 

60 comparing said deposited E-coin value m d with said hint 
value m H . 

4. A method as set forth in claim 3 wherein said E-coin 
generating step is performed by said signer. 

5. A method as set forth claim 4, wherein said receiver 
65 transmits said E-coin to said verifier, and wherein said 

verifier deposits said E-coin by transmitting said E-coin 
received from said receiver to said signer, and said signer 
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performs said confirming step on the deposited E-coin 
received from said verifier. 

6. A method as set forth in claim 3 wherein said signer 
stores a transcript of all hint values m h that it generates, and 
where said signer outputs an indication of a valid transaction 
if said message m rf matches any hint value stored on said 
transcript. 

7. A method as set forth in claim 3 wherein said signer 
stores a transcript of all hint values m h that it generates, and 
wherein said signer: 

outputs an indication of an invalid transaction if said 
message m^does not match any hint value m h stored on 
said transcript; and 

initiates a tracing procedure to determine the source of the 
invalid transaction. 

8. A method for verifying the validity of a digital signature 
S without compromising its anonymity in a system having a 
signer, a receiver, and a verifier, comprising the steps of: 

generating a hint generation value m e ; 

receiving a hint value m h generated by said signer based 

on said hint generation value m e ; 
storing said hint value m h ; and 

confirming said that said digital signature S is a valid 
digital signature using said hint value m h . 

9. A method as set forth in claim 8, wherein said step of 
generating a hint value m,, comprises the step of decrypting 
and blinding said hint generation value m e . 
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10. A method as set forth in claim 9, wherein said 
confirming step comprises the steps of: 

decrypting and blinding the digital signature S to create an 
encrypted digital signature S^; and 
5 comparing said encrypted digital signature S H with said 
bint value m h . 

11. A method for verifying the validity of a digital 
signature S without compromising its anonymity in a system 
having a signer a receiver, and a verifier, comprising the 

10 steps of: 

receiving a hint generation value m,; 
generating a hint value by said signer based on said 
hint generation value m tf ; 
15 storing said hint value m h ; and 

confirming said that said digital signature S is a valid 
digital signature using said hint value m h . 

12. A method as set forth in claim 11, wherein said step 
of generating a hint value m A comprises the step of decrypt- 

20 ing and blinding said hint generation value m tf . 

13. A method as set forth in claim 12, wherein said 
confirming step comprises the steps of: 

decrypting and blinding the digital signature S to create an 
encrypted digital signature S H ; and 
25 comparing said encrypted digital signature S H with said 
hint value m A . 

# * * * * 
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